Chrome now seems to force-change http:// URLs to https:// URLs.
As in, you paste a http:// URL into the address bar, and Chrome silently switches it to https://, and then complains the site is down.
No, this is not a HTTP redirect and no, HSTS is not involved. I tested this on a site that only has HTTP available.
This is bullshit. I tend to defend some measures like that, but this is taking it too far, making it seem like something that works – is not working.
EDIT: seems to depend on the version. I tested it on 135.x on Debian, another person tested it on unspecified but probably newer version on macOS. Others report other behaviour. Weird.
---
Yes, this happens also in Chromium.
No idea when the change was made, I don't usually use Chrome/Chromium. Might have been years, in fact. I am not saying this is new, I am saying this is dumb. 
No, it does not happen in Firefox.
The reason this bugs me is because this does very little to enhance anyone's security today, while at the same time it flat-out refuses to do what the person using the software explicitly told the software to do.
Compare with the "expired certificate" warning. User's intent is to visit a HTTPS site, but the HTTPS is broken due to expired cert. This can also be an attack. Makes perfect sense to have a scary warning!
Here, user's intent is to visit a HTTP site. HTTP is working. But nope!
Yes, HTTP is not secure. Most sites should really just switch to HTTPS – but newsflash, they already have!
Making it impossible to visit pure HTTP sites means that plenty of old sites, which might still have plenty of value today, become simply inaccessible.
At the same time, if a user clicks on a HTTP phishing link, they might just as well click on a HTTPS phishing link. 🤷♀️
Can I come up with a hypothetical scenario where this kind of forced scheme change saves someone from a an attack? Sure I can!
gmail[.]com DNS is hijacked in $COUNTRY. Alice clicks on a http:// link to gmail[.]com, and reaches a phishing site. Provides credentials, game over. Force-switching to https:// thwarts the attack.
You know what else thwarts the attack? HSTS – not the first time Alice visited gmail[.]com. Plus, that domain is 100% on the HSTS preload list.
Also, DNSSEC could help.
The hijacked site might be less popular and not on HSTS preload list, sure. But then the pay-off is way smaller for the attacker – is it worth hijacking DNS?
The attacker also *still* has to navigate HSTS headers probably already cached in the browser.
I simply don't see how forcing HTTPS directly by the browser meaningfully improves security for anyone.
But I can see how it makes a large part of the old Web inaccessible.
So, #FuckGoogle.
@rysiek Makes also quick local testing when you start your own server on localhost, or try to log into some behind-NAT local admin pabel, etc. impossible.
I don’t want to issue self-signed certs for private IPs for one-off temporary services only to have the browser allow me to visit them.
@rysiek "while at the same time it flat-out refuses to do what the person using the software explicitly told the software to do"
Exactly this. I expect software to do what I ask of it, not try to interpret my intent.
@rysiek for clarity re: Firefox
It can actually do this if you want it to, but the default is, I believe, to try https first and quietly fall back unless the user specified http.
This is new behavior and seems like a sane way to do it, too.
@cwicseolfor @draeath @rysiek about:config has an option for this but in my experience with how Mozilla did this it quickly tries http before switching to https. I have a few internal http sites and it generally tries 80 when I want it to.
Chrome completely bypassing any attempts on the url is dumb. At least Mozilla seems to try/warn first.
Does passing :80 as part of the URI work? I haven't used chrome for years...
@ge0rg @cwicseolfor @draeath @rysiek
firefox/librewolf have this thing where you can change settings under the hood.
Try changing browser.fixup.fallback-to-https to false and try again.
Yes, this is global and not exclusive to your ONE dev thing you need constant http:// on, but hey, you're an adult and can make your own bad decisions. (that's a good thing)
@draeath @rysiek Firefox supported HSTS in an annoyingly correct fashion for a while, while Chrome didn't, so even if you had that 'HTTPS-only' or 'automatically upgrade' options disabled you could find your HTTP connection to a subdomain resource being upgraded to HTTPS if the HSTS policy on the parent domain has includeSubDomains.
This broke internal websites at my $DAYJOB.
@Mayabotics What do you mean? According to RFC 6797 there are only two options for HSTS, the maximum age and include subdomains. So how did Chromium work incorrectly if it applied the policy to all subdomains if specified?
@waldi @rysiek @draeath At the time, Chrome wasn't honoring includeSubdomains for the internal subdomains that I tested, while Firefox was. (I remember it driving me nuts for months, because the affected internal URLs would be force upgraded to HTTPS and then fail to load in Firefox if I used their FQDN, while relative hostnames would allow HTTP access.)
Oddly I'm now seeing the opposite behavior when I just checked, so I suspect there is either some nuance to HSTS policy querying & caching that I'm unaware of because I don't regularly work with web tech, or our IT department has been trying different browser policies over the past year. (Or both.)
@spstanley lol. Yeah, I don't usually use Chrome. This just came up because somebody else stubbed their toe on this.
@rysiek I've just tried and it's not doing it for me (Windows 10, Chrome 136) - even for https sites with HSTS
I did have something very similar with Firefox though. It sometimes caches that it has done this and then will persistently do it in future. I have an internal http-only site and one day it decided to always switch to https (unless I accessed by IP address). What I did was to to reset site settings (which lost auto-complete, etc.).
@sborrill interesting. I am going to guess there is a setting somewhere, which might have gotten disabled.
I tested this on a pure Chromium install with no manual overrides.
@ThePfromtheO @Lazarou nope, I was using default settings in a clean VM.
And that's after a person independently reported it to me as a problem.
@rysiek I operate a page that’s only available via HTTP (and has never been on HTTPS). It still loads fine in Chrome 136.0.7103.93 and 136.0.7103.48, so this doesn’t fit to your conclusions that Chrome wouldn’t do that any longer.
Did you try Chrome in a “fresh” environment, i.e. new user, new install?
@rysiek I believe it's been doing this for a while now.
This question about it was asked 6 years ago, and has been answered with a solution:
https://superuser.com/questions/1400200/chrome-persistently-redirecting-to-https-for-http-site
Michał "rysiek" Woźniak · 🇺🇦
silmeth 🇺🇦
Brett Sheffield (he/him)
draeath
cwicseolfor (has moved!)
kajer :notverified:
superbeelavaman
Ge0rG
Maya
waldi
sijmen
spstanley
Spoon
Stephen Borrill
Lazarou Monkey Terror 🚀💙🌈
ThePfromtheO
0x575446, Fifth Columnist
Shdwdrgn
Jeremy 🇨🇦
Daniël Franke 
/mərˈkjʊriəl/
Bill Zaumen
Xeniac
Irina
Götz Hoffart
Neko 
🍻 Alexander 🇪🇺