Hacker News Reader

Comment by jacobwil | Hacker News Reader

My favorite version of this trend remains http://alwayshttp.com because https://alwayshttp.com doesn't work since alwayshttp.com:443 doesn't connect.

On the other hand, it's possible to reach https://coffeeshopwifi.com and (with a cloudfront certificate error) https://neverssl.com which makes me wonder if something in whatever I'm using is trying to upgrade to HTTPS when I fail to reach them.

View on HN

Huh, I don't even get a certificate error on https://coffeeshopwifi.com/ - and I got automatically upgraded (I guess due to https everywhere) haha

Browser extensions will redirect HTTP to HTTPS as the request is made, so CoffeeShopWifi can't help you there.

Most sites will send a redirect to HTTPS, which CoffeeShopWifi does not.

So I decided it's safe to make a cert and support HTTPS.

> Browser extensions will redirect HTTP to HTTPS as the request is made, so CoffeeShopWifi can't help you there.

They could stop serving port 443. That would prevent any extensions from automatically upgrading.

That is why I use x.com also has a very shall payload

Getting "you had one job" vibes here.

It's actually a moderate pain to set up something that doesn't answer on port 443 unless you want to host it yourself. I tried with http://wifi.help, but it's at Cloudflare and I don't know of a way to block port 443 without paying for their WAF.

httpforever.com is the one I use. https connection gets redirected to http to ensure that it gets captured.

I think you're misunderstanding the GP. The HTTPS connection will not be redirected when you are behind a captive portal, you'll receive an invalid certificate error (when the captive portal tries to serve itself at that address) or the website will simply not respond. Only if the HTTPS response is cached in your browser would the redirection work behind a captive portal.

You’re 100% right, thanks for the correction.

Reply on news.ycombinator.com