[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 was making the case specifically where a user does not need to enter sensitive information. HTTPS should always be used in that case of credentials and payment info.. 
-- 
Alexander Roscoe
Comcast - Wireless Engineer
Phone – 215.286.7283
Cell – 215.609.2691

From: "Linss, Peter" <[email protected]>
Date: Tuesday, October 6, 2015 at 3:07 PM
To: Alex Roscoe <[email protected]>
Cc: David Bird <[email protected]>, Michael Richardson <mcr+[email protected]>, "[email protected]" <[email protected]>
Subject: Re: [Captive-portals] A new draft / idea - draft-wkumari-capport-icmp-unreach


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