[Sovereign Keys] The captive portal problem (and a solution?)

[Peter Eckersley]

(Thanks to agl for pointing out the seriousness of the second half of this
problem)

There are at least two layers to the captive portal problem.  

1. The first is that if we implement secure HTTPS-only semantics for most
major websites, captive portals' attempts to hijack their users will fail.
That makes it hard for unsophisticated users to supply the credentials/ransom
that these networks request.

We have this problem today with HSTS and HTTPS Everywhere.  It would get worse
if DANE, Sovereign Keys, or some of the other proposed TLS authentication
enhancements were deployed.  We need to build a user interface that notices
hijacking attempts in a reasonable way, and says something like "this network
is preventing a secure connection to google.com.  Would you like to make an
insecure connection to hijack-me.com instead?"

2. Any TLS authentication enhancement that requires a side-channel (DANE with
client verification, Sovereign Keys, Perspectives, Convergence, etc) must
either fail unsafe, or will be deadlocked if a captive portal tries to use
HTTPS for its authentication process.

The one side channel that we know still works in this situation is the X.509
cert chain itself.  Except that isn't a safe communications method,
because attackers can strip your special certs off the end of the chain and
just show you a simple chain signed by a compromised CA.  Perhaps one day we
could build clients that /demand/ new things in the X.509 chain, and fail if
they're absent, but that's not going to happen this decade.

My current proposed solution to the side-channel/captive portal deadlock
problem is to build and maintain a whitelist of the domains that captive
portals hijack users to.  We could use the Decentralized SSL Observatory, or
better yet, instrumentation in a major browser, to collect this (it's the set
of domains that many other domains are 302'd to on certain networks only).

The whitelist needs to be used in such a way that it never decreases the
security of any real (non-captive portal) websites.  With Sovereign Keys
that's fairly easy: if you ever see a Sovereign Key registration for a domain
on the whitelist, you immediately remove it from the whitelist.

https://git.eff.org/?p=sovereign-keys.git;a=blob;f=issues/captive-portals.txt;hb=HEAD

-- 
Peter Eckersley                            pde at eff.org
Technology Projects Director      Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993