[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Captive-portals] A new draft / idea - draft-wkumari-capport-icmp-unreach



I am not sure requiring HTTPS here really addresses the attack surface. If someone hijacked DHCP, they could point the user to their own HTTPS site ready to take payment. 

I don't think anyone disagrees that when taking sensitive information from users, it MUST be using HTTPS (and the user should, though they often don't, check the hostname is one they "trust" giving money/info to). This isn't, however, a problem limited to CP networks, nor one we need to solve, imho.

The risk of requiring certs for the CP-NAS interface is that WISPs will probably just use self-signed certs and make the user suffer the browser warnings... (Or, worse, they will not use the spec and everyone has a Legacy experience). 


On Tue, Oct 6, 2015 at 12:07 PM, Linss, Peter <[email protected]> wrote:

On Oct 6, 2015, at 11:23 AM, Roscoe, Alexander <[email protected]> wrote:

I am really a big fan of having the ability to pass FQDN as a DHCP option.  I assume all un-authed users will have access to DNS.  There are some edge case scenarios will this will fail, especially in mobility situations where a roams between 2 of the same SSIDs that have a different DHCP server and cache. I think an ICMP reply would offer another mechanism to determine the clients state.

I do not think HTTPS should be a requirement, this should be left to the discretion of the the hotspot provider.  Many hotspots, especially in the U.S. require users at a minimal check a terms of service box to get internet access.  An application like this would not need to be secure as there is no sensitive information being passed.

I strongly disagree with this sentiment. These days HTTPS should be the default for all new features, and HTTP only used when there is a technical requirement preventing the use of HTTPS. We want to make the net secure, not add more attack surface.

There have already been reported incidents where the attacker joins a public wifi and hijacks DHCP. The user should have some assurance that the captive portal they're entering their credit card info into is the right one.

Peter