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

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



On Tue, Oct 6, 2015 at 1:45 PM, Michael Richardson <[email protected]> wrote:

David Bird <[email protected]> wrote:
    > Though, having a SSL cert doesn't necessarily mean it's the "right"
    > website.  I don't think we have to require HTTPS in all situations, but
    > I could be convinced otherwise.

Absent the problem of the web-CAs being corrupted, HTTPS means that the name
in the browser location bar, and the web site reached are the same.

Yes, of course. But, you still don't know it is the 'right' site, necessarily. 
 
The browser makes decisions about what to send based upon that data, so
that's why it matters.

HTTP can't promise that.


The browser (and hopefully the user!) make decisions based on the domain name and HTTPS status. A user, obviously, should NOT enter information into a site, even if using https, if the user doesn't trust that domain. (nothing here is CP specific).

That said, I see the potential value of having a FQDN in DHCP that can be matched up against the HTTPS CP-WEB application. But, in my suggested changes, the DHCP option isn't telling the client the CP-WEB location. It is instead telling the client the CP-NAS location (which isn't https).  [Having DHCP give out URLs to CP-WEB directly will require that DHCP be part of the NAS given that the CP-WEB URLs are typically device/session specific in the query string parameters].

 
    > I don't disagree... My point is simply that a network, Open or
    > otherwise, without CP (or with CP that whitelisted the OS CP detection
    > end-points) render this sandbox browser feature useless. Moreover, why
    > would a Client STOP using the sandbox browser after "authentication"
    > (does the client all the sudden trust this (probably open) public
    > access network more now?).

Using a sandboxed browsers for HTTP sites makes a lot of sense to me :-)


I think it makes sense, but not because it detected a CP, rather because the user has classified the location as "Public access" (vs. Home or Work, etc). It doesn't make sense to me that a Client will be more suspicious of a CP network vs. any Open SSID w/o CP or that the Client starts to "trust" a (open) network only because it passed the CP. I'd be happy if Clients treated ALL Open SSIDs automatically as "Public access" and always used a sandboxed browser for HTTP, even after interacting with a CP. 

David