On 07/14/2015 10:43 PM, David Farmer wrote:
OK fine TLS, but don't pick on me, Ted you said SSL in your list, I
was just going off of that.
Sorry, that was as much for my benefit as yours. You are right that I
tend to use the terms interchangeably, but the time has definitively
arrived at which we need to stop doing that.
However, I'm not sure it really makes that much difference, it isn't
what our captive portal does that will be your issue it's what be bad
guy's captive portal does and there ain't much we can to about that.
And I'm not sure how much TLS will really help there, as SAM points
out domain names and certificates are that hard to come by, not really
an excuse for the good guys to not do it, but its not going to fix the
problem either.
The point of saying that captive portals have to support TLS and
DNSSEC+DANE is to arrange it to be the case that only bad guys have
unsecured portals.
The only thing we can really do is NOT have you use insecure open
wireless by providing secure wireless options. But, I'm some what
depressed by the number of people who WANT to use insecure open
wireless for many reasons, ease of use, anonymity, etc...
The main reason they want to use them is because they work. Remember,
secure != non-private. The captive portal can collect information
about the user, but it doesn't have to. The main reason people use
broken or non-secure captive portals is because it's so hard to make
captive portals that are secure, so by and large captive portals simply
are not secure.
For instance, suppose I want to sell a router that has a captive portal
mode that can be enabled by the end user. How do I make that work
without requiring the end-user to buy a cert? Right now the answer is
that I don't, because no browser supports DANE certs. How do I do
secure password-less logins? I don't, because there isn't a good and
well-supported standard for doing that, even though we know how.
So part of what we should be doing to make Christian happy is to finish
the specifications for these security technologies and see them deployed
in browsers and servers. There is no reason other than our failure to
do this that it should be the case that I have to log in to my Wifi
router using an unencrypted connection that reveals the username and
password I use to authenticate, much less that captive portals should
have to either not be secure, be secured with an expensive SSL
certificate infrastructure, or be "secured" with a key that can't be
validated.