4 ms·

I don't understand how this (and other similar sites mentioned) work. What is going on with the network that makes visiting a non-SSL site make it work? Anyone

I don't understand how this (and other similar sites mentioned) work. What is going on with the network that makes visiting a non-SSL site make it work? Anyone care to offer an explanation or have a link to one?

gattilorenz 5y ago
Basically, because the captive portal tries to redirect the browser to a page for authentication, but the browser won't let this through on a https connection for security reasons. https://en.wikipedia.org/wiki/Captive_portal#Require_Web_Browser https://en.wikipedia.org/wiki/Captive_portal#Require_Web_Bro...
- iso1210 5y ago
  Wifi with captive portals work by redirecting all of your outgoing traffic to a specific host - send a packet to 12.34.56.78 and it gets natted to 10.0.0.1 (or wherever the captive portal is). When you connect to wifi, many (most?) OSes and/or browsers issue requests to http servers run by apple/firefox/microsoft. If the response is a portal, a popup is shown to allow the user to login (typically logging in would authorise the IP and/or mac address in a database and allow traffic to pass). However some (poorly implemented) hotspots have specific holes to allow these pages to load without the portal (whitelisting the domains), then when you try to visit http://othersite.com http://othersite.com, you will be redirected. Other portals may timeout after X minutes or X MB of use and require reauthentication, which the OS/browser may not detect. As more and more sites use https, while the connection can be stopped (by stopping traffic going to port 443), a correctly behaving browser should ignore any traffic coming from a redirected https connection, as it wouldn't have a valid certificate - it's the whole point. Many sites also implement headers which tell a browser "you will always connect to me on http", and the browser will refuse to downgrade to http://othersite.com http://othersite.com, even if port 443 (https) is blocked but port 80 is open. By visiting neverssl.com or similar sites, you can in those situations trigger the captive portal login page.
topher515 5y ago
The way a captive portal works is that the router at the coffee shop sees your browser's DNS request for `google.com` and instead of responding with the real IP address for Google it lies to your browser and returns an IP address which it controls. If google.com were a non-HTTPS website then the router could simply then serve up any arbitrary content it wanted. i.e., it's own login/access form. However, since google is an HTTPS website, the browser asks for an HTTPS certificate from this fake google.com and the router is unable to deliver a "real" certificate—this then breaks the "login flow" since instead of seeing a login form you see a "danger, do not continue, bad certificate" page.
- moftz 5y ago
  You now also end up in the situation where your browser has the google.com certificate pinned so even if the portal tries to serve up a self-signed certificate for google.com, the browser will still complain about something fishy going on. The most complete solution is for the browser to try to detect captive portals and load up a plain HTTP website for the portal to hijack. I remember in public school, IT had a website blocker that was effectively was a captive portal that would just route you to a "BLOCKED" web page and only could handle blocking non-HTTPS domains. Many sites were already going HTTPS by senior year so it was trivial to go to https://facebook.com https://facebook.com and have full access. Another possibility was using a cgi-proxy. The site blocker was a blacklist so I hosted my own cgi-proxy when the one commonly used got blacklisted.
  - boring_twenties 5y ago
    Um, your browser would complain about a self-signed certificate even if there was no pinning. Otherwise SSL/TLS would be useless.

gattilorenz 5y ago

Basically, because the captive portal tries to redirect the browser to a page for authentication, but the browser won't let this through on a https connection for security reasons. https://en.wikipedia.org/wiki/Captive_portal#Require_Web_Browser https://en.wikipedia.org/wiki/Captive_portal#Require_Web_Bro...

iso1210 5y ago
Wifi with captive portals work by redirecting all of your outgoing traffic to a specific host - send a packet to 12.34.56.78 and it gets natted to 10.0.0.1 (or wherever the captive portal is). When you connect to wifi, many (most?) OSes and/or browsers issue requests to http servers run by apple/firefox/microsoft. If the response is a portal, a popup is shown to allow the user to login (typically logging in would authorise the IP and/or mac address in a database and allow traffic to pass). However some (poorly implemented) hotspots have specific holes to allow these pages to load without the portal (whitelisting the domains), then when you try to visit http://othersite.com http://othersite.com, you will be redirected. Other portals may timeout after X minutes or X MB of use and require reauthentication, which the OS/browser may not detect. As more and more sites use https, while the connection can be stopped (by stopping traffic going to port 443), a correctly behaving browser should ignore any traffic coming from a redirected https connection, as it wouldn't have a valid certificate - it's the whole point. Many sites also implement headers which tell a browser "you will always connect to me on http", and the browser will refuse to downgrade to http://othersite.com http://othersite.com, even if port 443 (https) is blocked but port 80 is open. By visiting neverssl.com or similar sites, you can in those situations trigger the captive portal login page.

topher515 5y ago

The way a captive portal works is that the router at the coffee shop sees your browser's DNS request for `google.com` and instead of responding with the real IP address for Google it lies to your browser and returns an IP address which it controls. If google.com were a non-HTTPS website then the router could simply then serve up any arbitrary content it wanted. i.e., it's own login/access form. However, since google is an HTTPS website, the browser asks for an HTTPS certificate from this fake google.com and the router is unable to deliver a "real" certificate—this then breaks the "login flow" since instead of seeing a login form you see a "danger, do not continue, bad certificate" page.

moftz 5y ago
You now also end up in the situation where your browser has the google.com certificate pinned so even if the portal tries to serve up a self-signed certificate for google.com, the browser will still complain about something fishy going on. The most complete solution is for the browser to try to detect captive portals and load up a plain HTTP website for the portal to hijack. I remember in public school, IT had a website blocker that was effectively was a captive portal that would just route you to a "BLOCKED" web page and only could handle blocking non-HTTPS domains. Many sites were already going HTTPS by senior year so it was trivial to go to https://facebook.com https://facebook.com and have full access. Another possibility was using a cgi-proxy. The site blocker was a blacklist so I hosted my own cgi-proxy when the one commonly used got blacklisted.
- boring_twenties 5y ago
  Um, your browser would complain about a self-signed certificate even if there was no pinning. Otherwise SSL/TLS would be useless.