This is a revisit of sorts of Another WTF Chrome and the even older Google Chrome Frustrations, but is yet another facet of an overall flawed design. Once again, I caught Chrome doing something which I did not want it to do. While I agree that using HTTPS everywhere you can is an "Extremely Good Thing™", the idea that Chrome would blindly "upgrade" a request to a http:// url explicitly typed as such to HTTPS before it even sends the request to a webserver in the same domain is half-baked at best. I have no problems with it assumed HTTPS if I just typed some-host.some-domain.com without the protocol, but to silently change an explicitly entered URL starting with http:// it going too far. But as of Chrome 147, which was released in April, Chrome is doing just that. And they are going to make this the universal default this Autumn.
I found this out by trying to access an internal host name to look at a code coverage report, but instead of seeing the report, I just got the message The provided host name is not valid for this server.. And for awhile, I thought I had somehow broken the configuration of the web server, which also serves this domain. But, in looking at Chrome's Developer Toolbox, I did not see a Host header in the request, and even looking at the packets sent to the HTTP port showed nothing, including the HTTP GET command. All I saw were packets for the SYN, SYN/ACK and ACK exchange, with no content. So I knew something was not quite right. And sure enough...
If you go to chrome://settings/security, and scroll down to Secure Connections, you will likely see this is turned on, and set to supposedly "Warns you for insecure public & private sites". This means that even though you have not defined the site as a HSTS domain (which you check by going to chrome://net-internals/#hsts and querying the domain), it will make the change without warning before even trying to make a request. And if the web server in question is setup with a HTTPS site in its default host, suddenly you find yourself getting results which make no sense, such as the secure application telling you that the host name the browser provided is not valid for the server. And there is no way to add an exception, as even configuring the site in question in chrome://settings/content/insecureContent does nothing. Your only option is to go to the Secure Connections section on the security page, and switch it to "Warns you for insecure public sites", or disable the feature entirely. So just like their implementation of "Secure DNS", which uses external DNS servers, to say that it is "half-baked at best" is being nice.
Why is this bad and "half-baked at best"? It is such because it does not warn you that it is bypassing things like HSTS, does not warn you that it is making the change, and most importantly, does not provide a way to add exceptions. The only option is to change the setting to partially if not fully disabling an otherwise good feature. And because even with solutions such as Let's Encrypt, you cannot get SSL on all internal devices without setting up an internal, private CA, which is a hassle, since every device has to have the root CA certificate installed on it so that it will trust private SSL certificates issued by the private CA. And complicating this is the fact that companies might have legacy equipment which only supports a SSL protocol which Chrome does not support, and had to drop back to HTTP instead of HTTPS for that equipment. I would almost say that in this case, the egg is not even cracked open in what could have made this almost as good as a meatloaf sandwich.
And so, now I have two settings I have to remember that Chrome might mess with in their idea of security, which instead break things (the other being Secure DNS).