This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

triggering hotspot login and https

we are using Sophos UTM 9 v9.408-4 with Wireless Protection, Network Protection etc

our users (200+) mostly students - are continuing to have problems with obtaining the hotspot login form after their device has associated with one of our wireless networks.

the main reason seems to be be that the login form only appears when the user attempts to access a website via http and NOT https

these days many people do not understand the difference between their web browser's address bar and the (typically Google) search box on their home page

Can someone explain why hotspot login can NOT triggered by ANY internet access (ie whether 80, 443, 993, 587 etc) ?

NB - we did not have this issue with our previous (Aruba) wireless system

or is it that I have missed a configuration fix ?

pls refer p453 of the Administration Guide v9.408



This thread was automatically locked due to age.
Parents
  • I'm replying to my own post having found this

    https://live.paloaltonetworks.com/t5/Management-Articles/Captive-Portal-Not-Working-with-HTTPS-Sessions/ta-p/78346

    that provider uses a method of 'known users' (which must also be available within SophosUTM since once logged in, internet traffic is allowed)

    unknown users are subject to a 'decrypt policy' for https so that the gateway device can determine if the traffic is outbound, if so then CP is triggered

    known users are subject to a 'no decrypt policy' for https so their traffic does not load the cpu or trigger certificate warnings

    Gary

  • This is an issue with a lot of hotspot networks now - as at least Android devices will default to https when looking for a captive portal. Seems like the palo alto solution is a smart way of overcoming it. Would be really great if Sophos could make a similar fix to the https issue.

  • Hi,

    most hotspots use HTTP redirect to present the captive portal. With HTTPS, the actual HTTP command is encrypted and signed. If a firewall now would reply with an encrypted HTTPS redirect, the browser would complain about an invalid certificate. 

    Palo Alto's solution works exactly like that (from https://live.paloaltonetworks.com/t5/Management-Articles/Captive-Portal-Not-Working-with-HTTPS-Sessions/ta-p/78346 )

    Explanation of the warning message

    Unknown users will be coming in from the wireless zone, and there is no way for them to install the self-signed certificate, so they'll get a warning message in case the decryption is in place.

    So every user has to accept an invalid certificate for a page he's browsing to. There's hardly a way for the user to differentiate between a valid usage scenario from a man-in-the-middle-attack and forcing them to accept these would lead to unwanted user behaviour: the user is asked to enter his account + password on a page a certificate warning showed up for. Furthermore, especially browsers like Google Chrome make it very difficult to accept an invalid certificate it already knows the right certificate for (like https://www.google.com ) .

     

    I hope this explains why we don't have redirection in place for HTTPS traffic.

     

    Kind regards,

     

    Dirk Bolte

  • Hi Dirk, and Andreas - thanks for your input

    I guess my initial response is - yes, CP is a problem in today's environment for the reason Dirk explains, but as Andreas implies, implementations such as Sophos don't help much

    Surely Sophos can find better ways to provide user auth for wireless networks ?

    I have been reading this

    https://tools.ietf.org/html/rfc7710

    which at least suggests some current options via DHCP

    that docco doesn't offer a full picture of a solution eg interaction with iptables but IF the Sophos UTM is providing dhcp then its conceivable that something like this could happen

    client requests IP from utm dhcp server

    dhcp server sees the client as 'unknown' -> serves option 160 (v4) or 103 (v6) incl uri of CP

    utm iptables treats client as unknown

    client responds with http request to uri -> auth or not

    if auth, utm determines client is known and adjusts iptables

    I presume that only the folks at Sophos can say whether/why this can't work BUT I would like to see some effort put into getting a solution

Reply
  • Hi Dirk, and Andreas - thanks for your input

    I guess my initial response is - yes, CP is a problem in today's environment for the reason Dirk explains, but as Andreas implies, implementations such as Sophos don't help much

    Surely Sophos can find better ways to provide user auth for wireless networks ?

    I have been reading this

    https://tools.ietf.org/html/rfc7710

    which at least suggests some current options via DHCP

    that docco doesn't offer a full picture of a solution eg interaction with iptables but IF the Sophos UTM is providing dhcp then its conceivable that something like this could happen

    client requests IP from utm dhcp server

    dhcp server sees the client as 'unknown' -> serves option 160 (v4) or 103 (v6) incl uri of CP

    utm iptables treats client as unknown

    client responds with http request to uri -> auth or not

    if auth, utm determines client is known and adjusts iptables

    I presume that only the folks at Sophos can say whether/why this can't work BUT I would like to see some effort put into getting a solution

Children
No Data