On 7/14/15 15:00 , Ted Lemon wrote:
On 07/14/2015 12:24 PM, David Farmer wrote:
However, what if the only purpose of the portal is to display
marketing and/or acceptance of Term & Conditions? Is DNSSEC and SSL
still required in this case? I tend to think not, but I'm happy to
hear why I'm wrong.
Frequently that is all the captive portal is, a little marketing and
maybe T's & C's to keep the lawyers happy. For most coffee shops or
restaurants and a lot of other public places this all the portal does.
The issue is that we want to avoid being infected by malware, and if the
captive portal controls all of our access to the information we'd use to
avoid connecting to an untrustworthy source, we are in trouble. Chances
are that your marketing splash is some kind of flash or javascript
thing, and we'd like to be able to know that we are really talking to
you and that you aren't on a malware blacklist. DNSSEC and TLS (not
SSL, all versions of SSL are known to be vulnerable to hacks of various
kinds) are required to make this work.
OK fine TLS, but don't pick on me, Ted you said SSL in your list, I was
just going off of that.
So to be clear your saying all captive portals even if they don't
exchange information with users need to be TLS and DNSSEC verifiable?
Correct me if I'm wrong, but I think that also means they need to be
using public address too, not RFC 1918 or ULA.
Personally, happy to do that, especially with a DHCP or RA option like
proposed. Because of the stupid way many apps deal with the
redirection, you need to redirect to a plain HTTP page first. Otherwise
TLS resources needed can be very massive in some situations, 100s or
1000s of redirects per second aren't unheard of. And, 100s or 1000s TLS
session per second is not something your going to do on a typical
wireless controller.
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 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...
We provide secure options and are working on proving easy ways to have
even visitors/guest use secure wireless. But honestly, most people
don't want to be bothered, I'm the bad guy tying to make their life
harder, or I want to monitor their usage or something.
--
================================================
David Farmer Email: farmer@xxxxxxx
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 1-612-626-0815
Minneapolis, MN 55414-3029 Cell: 1-612-812-9952
================================================