Last night I had an interesting interaction with Troy Hunt regarding TLS and browsers. More specifically, the Chrome browser, though all browsers are pushing this to various different degrees. HTTPS and TLS support for all websites is a worthy goal, but this push is also breaking the web. More than anything, people that shouldn’t ignore this seem to have blinders on. When the person you’re expressing the idea to isn’t listing at all. Either that person has no respect for what you’re saying, or is unwinning to upset the orthodoxy of what they believe. Believe me, I’ve fallen prey to this blinder’s way of thinking before, so no hate for the man. I do wish I wasn’t just ignored, however. When it was clear what was happening, I stopped trying to explain and moved on to, well, this.
Everything I’ll mention relates to Chrome version 91.0.4472.164 – on Windows 10.
I should mention, I’m a fan of HTTPS and TLS. I’ve disagreed with others who don’t like it. The site you’re looking at, my blog, is secure. The general rule is to enable TLS whenever possible, if possible. The web needs to be more secure and I support this. I have fought to secure several tools that weren’t built with this in mind. These issues are issues I work on all day at my IT company CWL. What I don’t support is breaking things for users in pursuit of that end.
HTTPS everywhere has become a religion
Yes, it seems that anyone who sees the value of encryption web traffic everywhere is drinking the Kool-Aid in ways that help them completely ignore evidence that bad things happen as a byproduct. There’s a kind of proselytizing attitude amongst people like this. They seem to think because something is encrypted “it’s safe” and if it’s not encrypted, “it’s a risk.” First and foremost, that’s stupid – the bad guys know how to encrypt things too. Being safe will always require more than what encryption tools and technologies can provide. Shit, the biggest scourge in malware today are applications that encrypt data.
“No, but it’s secure!” Come on.
Yes, it’s important to promote more secure everything, it becomes a problem when we’re so blinded it breaks other things in the process.
Breaking the web
One particularly interesting scenario as a byproduct of enforcing TLS is when one attempts to download from a TLS-based website using a non-TLS connection. I’m not sure what version Chrome did this, but they basically dropped so much of their support for that scenario that the user has to click several times to get the file if they want it. In fact, clicking on the download link will actually do nothing.
Do you want to see what this looks like, click here. That link is simply a link to download NGINX binaries. Chrome is seeing that the link is on a TLS site (this one), possibly coming from a different domain (the link points to nginx.org) and that it’s non-TLS. Now, to get that file, you’re going to have to know that it involves right-clicking on the link to “Save Link As…”, Bypassing a prompt that says the file “can’t be downloaded securely” – a prompt that actually gives no outward indication of how to bypass it. The only button the user sees is “Discard” as if this is the only option.
So, yes, you figure out that you have to click the up chevron and choose “Keep” to get the download started. As far “supported,” yes this is functionally possible, but as I said to Troy, a user will never be able to navigate these sorts of actions. Even worse if a site uses Javascript to enact a download (no possibility of a right-click) or if the site attempts to disable right-click. Now, you may think this is good for security, and maybe it is, but you can’t say it isn’t broken.
Why hasn’t Nginx updated their site? Who cares. They haven’t gotten to it. The web is full of sites that haven’t yet changed. many of these are individuals or companies that are still just getting to the web. Some of them, in poorer countries, don’t have the technical wherewithal to yet bridge the gap on TLS. Some, like my local newspaper, may not have a skilled staff or maybe so precariously alive after a stifling pandemic that the thought of TLS on their static website is secondary to survival. Everyone has reasons, and they’re all fine because the web was mean to be open. Google may not like non-TLS, but they are not allowed to make these sites harder to use or break them.
Break it even more
Then, one gets to HTTP Strict Transport Security (HSTS). This is a policy that enforces TLS only across a domain. The average user won’t come across this, but if you build websites, you will. The idea is, that when you hit a website that supports HTTPS, and HSTS is enabled (think it is by default in many products), then Chrome will not let you hit any other none-TLS site on that domain. ”
Yes, great! That means it’s always going to be secure! A win for safety!”
Not so fast there. As a developer or a web builder, this automatic, in the background bullshit only causes grief. Anyone who’s worked with something like Docker, for example, knows the challenges of networking, internal ports, and working with reverse proxies. These things can be challenging alone, and when HSTS is incorporated, you’ll waste countless hours having to disable to counteract that. You’re trying to troubleshoot and build a site that should be working and you get errors completely unrelated to what you’re doing:
“Privacy error: Your connection is not private” (NET::ERR_CERT_AUTHORITY_INVALID).
In nginx, as an example, you’ll have to set a header using the following statement:
add_header Strict-Transport-Security “max-age=0; includeSubDomains”;
None of that will work unless you go to chrome://net-internals/#hsts and clear the thing min the first place. As a tool, HSTS might be great if we could turn it one when needed, not have it foisted on us.
These are just two examples of other things I’ve seen while using Chrome. Every day, more and more heavy-handed things are happening in the browser, forcing basic and fundamentally useful functionality to break. It’s important to mention that, just because a link is insecure, it is not always a risk. The risk is inherent in the user, what site they connect to, and the ultimate outcome of the process.
Even Troy himself in his live Youtube show argued a different version of this. He talks about how a padlock next to a web address “doesn’t mean it’s safe,” and that this iconography can mislead users into thinking the actual site itself is safe. That sort of visual in a browser might “break” the process of seeking out a safer web, huh? Maybe they ought to change it, as I suspect Google will. In a world where arguments about that are heard and acted on, but because it’s not secure – it’s ignored; that’s not the open web.