http://neverssl.com remains for those badly-setup wifi networks.

Or alternatively http://httpforever.com/

Similar to HTTPS-only being built into web browsers, isn't captive portal detection built into all modern OSes? What's the badly-setup wifi network that requires you to open your browser but doesn't get detected properly by the OS as a captive portal?

it isn't so much "badly" set up as maliciously set up. Captive portal vendors like to find ways of defeating the operating system's captive portal detection, because it hinders their ability to show ads after the captive portal login process.

Many don't because the captive portal works differently than the regular browser, I'm guessing. If you exit the captive portal on iOS (say to look up a password), you can't just go back to it, you have rejoin the network and start over.

It's funny that if I navigate to this site with HTTPS-only mode, it redirects to an HTTPS page.

Beat me to it. beats the hell out portscanning the subnet at the airport

Thanks! I'll stop using captive.apple.com now that I know about this!

You can also use example.com. I find that easier to remember.

The example names are just examples, it so happens that today they have a web site and it isn't HSTS. Tomorrow maybe they have HSTS. The week after maybe they get rid of the web site. The names are merely examples, and so it's probably a bad idea to use them for any other purpose.

Cool, they even generate subdomains dynamically to avoid caching

There are still places that don't auto-redirect to https for some reason. Maybe a temporary misconfiguration. I just ran into http://www.mbsonline.gov.au today and was surprised it didn't redirect and has broken https, even though that org really shouldn't do that.

A redirect itself is considered bad by some because it encourages relying on http in the first place (imagine always hitting a web site through http and expecting a redirect instead of going to https directly).

As soon as you do that, you are similarly prone to MITM attacks: on an insecure network, you hit an http site and it replaces the redirect with one to a https site that looks like the same domain but really isn't (with a valid cert for mbsonline.gov.au.foo.io).

For my personal sites, I prefer to go with no redirects and if it really processes data, https-only.

For users, the right solution isfor browsers to always attempt https first even if those could be technically serving entirely different content (that would be one hell of an anti-pattern though, so I wouldn't worry about it).

A permanent redirection before setting the correct headers is the best you can do at the server side.

Yes, the user is using insecure practices, and no, you can't correct it on your server.

I am arguing that the best you can do is not even have HTTP enabled.

A permanent redirect is the second best ;) And yeah, most practical for commercial entities (which is why I highlighted what I do for my personal sites).

No, you're actually less secure without HTTP. Scenario: someone figure out how to mitm your http traffic. You visit the page:

For the first time - you're affected either way.

For the second time - if you still have the permanent redirect cached, you avoid the mitm.

Disabling your own http only helps the attacker in specific situations.

My point is that you want to "educate" visitors to never use HTTP (eg. for their bookmarks and typing the URL in), which I hope is effectively achieved by not having HTTP web site even on a connection you trust (eg. your local network) — so if you succeeded in "educating" them at least for your web site, they are similarly protected when they come back, including from another device. If they only rely on their browsers caching the permanent redirect, they are protected for a short time on the same browser.

But ultimately, browsers have to default to HTTPS for a guaranteed "protection" from the start (whether that's through HSTS preload lists or simply by defaulting to HTTPS, does not matter much).

The best you can do is set HSTS and redirect from http to https.

You not serving http won't prevent a MITM from serving http to the victim.

There's a corner case where users who have never visited your domain (either ever or just on that browser) do so for the first time over a malicious connection. In this case, Mal sends them a page that looks reasonable, they create an account or login or whatever, Mal gets the password and probably proxies the requests to the origin domain (properly over https so even if the site operator redirects all pages to https, this still works) so that the user gets the email confirmation or whatever.

A tiny bit better is to submit your domain to https://hstspreload.org/ so that (major) browsers force https on the first connection. You should still set the HSTS header of course, it's a requirement for inclusion in the preload list and it should also catch people who have a browser from before your inclusion in the list or browsers that don't support the preload list at all.

You could also choose names whose parent domain is already HSTS pre-loaded. The .dev TLD is pre-loaded for example.

What happens if your browser (eg. new device, another browser, first visit) does not have a record of HSTS data for a domain, and you visit it by going to HTTP on an insecure network?

Can't they similarly serve HTTP data without any HSTS headers? Or do browsers also check HTTPS for any HSTS headers on the same IP and cross-compare?

I've been using HTTPS-only mode on Firefox for many months now. The place where I see HTTP links most often is email tracking links. I'm commonly automatically upgraded to HTTPS and it works but very often there is no HTTPS support at all. Even for sensitive things like password resets that have secret tokens in the URL.

A few sites I run into once in a while have the following bad setup, which HTTPS-only flags (because it's actually unsafe) but looks normal to most people:

1. http://www.example.com/ exists and redirects to http://example.com/

2. http://example.com/ also exists and redirects to https://example.com/

3a https://example.com/ works fine but

3b https://www.example.com/ does not exist

4. External links go to http://www.example.com/stuff/goes/here

You will also see the mirror image mistake (www.example.com is canonical, but the redirects go from example.com only on HTTP) at similar rates.

This is all because Tim chose not to rely on SRV records to make his toy hypermedia system work and decades later we're still paying for this (among others) mistake.

One website not supporting HTTPS which caught my eye is http://paulgraham.com/

I'm surprised by the number of German websites (.de) I've encountered this year that don't support HTTPS. I think they're all small businesses or personal sites, but still unexpected.