The widespread deployment of TLS and HSTS are great for the web, but they may present a problem if you connect to a WiFi access point that uses a captive portal. The problem occurs when an access point tries to redirect you to a portal login page: if the original site you were accessing implements best security practices, it will be in your browser's HSTS list and the access point won't be able to perform a protocol downgrade. Many browsers and operating systems implement some type of captive portal detection to avoid this situation, e.g. by explicitly checking for captive portal behavior immediately after a device connects to a new WiFi access point.[^1] But sometimes these heuristics might not work, especially if the active portal implements its own active-portal-detection-detection.
This weekend I set up nossl.io to debug these problems. The site doesn't have a TLS certificate and won't present HSTS headers, allowing captive portals to do their dirty deeds. Other people have built these services before, but I can never remember the domain names for the other sites so I made my own. To make the site a little more interesting, I made it respond with text/plain content describing the connection and a reconstruction of the original request.[^2]
[^1]: E.g. details about the Firefox implementation can be found here. [^2]: The reconstructed request is an approximation returned by Go's httputil.DumpRequest.