If I want to load some unencrypted data my browser better fucking let me do it. I don't mind if I have to give a secret handshake, but I have no sympathy for lusers who type "thisisunsafe" and then make it someone else's problem when their expectations of "safety" are violated.
AnthonyMouse · 5h ago
We started off with SSL/TLS being used for payments systems and logins where its absence is very important to not ignore. Then we said we should use it for everything, which is good, but now it's showing up in different contexts.
If it says the certificate for your bank is expired, you need to stop. If it says the certificate for the 10 year old public blog post that was linked by a 5 year old Reddit post as describing the solution to your problem, that should not matter, and you just want to read the non-secret contents of whatever is on that page regardless of whether the site's maintainer turned on HTTP to HTTPS redirects and then neglected to renew the certificate.
And people understand this, and people are rightfully going to devise workarounds for the second case, and it's ridiculous to expect them to not.
seanwilson · 5h ago
> We started off with SSL/TLS being used for payments systems and logins ... If it says the certificate for your bank is expired, you need to stop. If it says the certificate for the 10 year old public blog post that was linked by a 5 year old Reddit post as describing the solution to your problem, that should not matter
Non-HTTPS pages can be tampered with to inject any content into them e.g. into a blog post page, you could inject a login form ("sign in via Google to unlock this post"), a donation payment form ("donate for more content like this!"), or malware installers ("your browser is out of date, click to update" banner).
I think pushing to protect non-tech savvy users makes sense here. I see even a lot of developers not understanding risks like the above, so it's a losing battle thinking non-techy users can be educated about it and be cautious enough.
snickerdoodle12 · 5h ago
> Non-HTTPS pages can be tampered with to inject any content into them e.g. into a blog post page, you could inject a login form ("sign in via Google to unlock this post"), a donation payment form ("donate for more content like this!"), or malware installers.
Who cares? The blog author could be malicious. The blog might have been sold 5 years ago and now hosts malicious content.
Stop trying to nanny people, it's unbecoming.
krior · 4h ago
But you can atleast acknowledge that there is a difference between trusting a blog you are actively seeking out and all the entities between you and said blog, right?
snickerdoodle12 · 4h ago
Not really. The context is some random reddit post from close to a decade ago linking it. Might as well have typed a random URL in your browser.
charcircuit · 3h ago
The people getting their money and accounts stolen care. The blog owner cares about the reputational hit. People who care about the success of the web care because it makes the web more risky than people using mobile apps.
Dylan16807 · 2h ago
> The people getting their money and accounts stolen care.
> People who care about the success of the web care because it makes the web more risky than people using mobile apps.
The main comparison here is whether a middleman injected it or the blog inserted it server-side. The level of risk is similar either way.
> The blog owner cares about the reputational hit.
If the blog hasn't been updated in ages, they probably don't.
charcircuit · 1h ago
>The level of risk is similar either way.
There is still risk, but this is a form of risk which is not neccessary and can be reduced.
>If the blog hasn't been updated in ages, they probably don't.
We are talking about blogs that don't use https because they don't sell things. Expired certificates are out of scope of this comment thread.
Dylan16807 · 2m ago
> There is still risk, but this is a form of risk which is not neccessary and can be reduced.
It reduces it a little bit. But if you drop the risk of a random site being malicious by 25% that's not a very important change. The user still has to be wary. That reduction is not worth anything as drastic as blocking the site.
> We are talking about blogs that don't use https because they don't sell things. Expired certificates are out of scope of this comment thread.
I don't think we are?
"If it says the certificate for your bank is expired, you need to stop. If it says the certificate for the 10 year old public blog post that was linked by a 5 year old Reddit post as describing the solution to your problem, that should not matter, and you just want to read the non-secret contents of whatever is on that page regardless of whether the site's maintainer turned on HTTP to HTTPS redirects and then neglected to renew the certificate."
snickerdoodle12 · 2h ago
Yes and if you slit your wrists with a knife you will likely die. Do stupid things, bad things happen. Stop nannying people.
charcircuit · 2h ago
So visiting a website is doing a stupid thing? Your recommendation is essentially telling people to stop visiting websites or accept bad things will happen to them. This is not a healthy viewpoint for growing the web.
Dylan16807 · 2h ago
The stupid behaviors listed above are putting your google password or payment info into a random blog, or running a program it gives you because it says you need to update.
Doing that is stupid whether it's http or valid https or broken https.
charcircuit · 1h ago
Okay, but if a user went to a http version of YouTube and put in your payment info to buy a movie, as opposed to remembering it should take him to an https Google page, I would find that a plausible situation that is hard to blame the user for. Attackers being able to hijack the reputation of sites is problematic.
Dylan16807 · 4m ago
> Attackers being able to hijack the reputation of sites is problematic.
And the whole point of this thread is that some sites have 0 reputation to hijack.
Dylan16807 · 4h ago
> If it says the certificate for your bank is expired, you need to stop.
No I don't. At least not if it's recent. A certificate that expired in the last month is roughly equal in safety to a certificate that's valid for another month or two.
Expiration is a backup safety measure and the risk is mostly based on how long it's been since the certificate was issued.
Unless any banks are going around leaking keys right after they expire for some weird reason?
yarekt · 4h ago
Err what? That certificate may well have been leaked, but because it expired the bank doesn’t not consider it an issue, no need to revoke it.
Certificate validity is binary. either it all is, or it isn’t. this included “not before”
AnthonyMouse · 3h ago
Not only that, banks are generally pretty diligent about that sort of thing and have enough customers and resources that if their website is misconfigured someone is going to report it immediately and they're going to fix it immediately. Which means that a certificate error on a bank site is suspicious.
Whereas a certificate error on a disused blog is pretty much what you'd expect from a disused blog.
whydoyoucare · 4h ago
We scream at the expired certificate, yet happily let CloudFlare be an official MitM. How ironic is that? :)
Dylan16807 · 2h ago
The chance that happened is pretty low. What kind of breach gets old keys but nothing else of note?
tptacek · 5h ago
The browser does not know what the web page is, and attacks on genuinely sensitive websites like banks wildly outnumber attacks on 10-year-old public blog posts. Browsers are doing exactly the right thing here.
AnthonyMouse · 4h ago
The certificate error on the 10 year old blog post isn't an attack, it's an old site that still exists but isn't actively maintained, which happens all the time.
tptacek · 4h ago
The browser cannot know that.
AnthonyMouse · 4h ago
That's why you need the human who can know that to make the decision.
akerl_ · 2h ago
Isn’t that what’s happening? The browser shows a big warning with context and then the human makes a decision to click the “do this it’s fine” button.
The exception is cases where the site operator has opted in to HSTS or similar to indicate their decision to rather disable access than allow insecure access.
alt187 · 5h ago
To be fair, you can click Advanced > Continue to something or other to bypass the SSL warning.
I think.
molticrystal · 5h ago
For several types of certificate and ssl issues(HSTS , blacklisted/revoked certificates) that option is hidden and thus unavailble. Chrome can be a stickler, which is understandable as the majority of its users are not prepared to deal with the possible downsides of going to an untrusted page.
I remember reading some blog post that badly configured SSL certificate will cause something like 90% of people bouncing off the website because they are scared of the big red Chrome warning. SSL certificate is actually an important UX factor.
toast0 · 5h ago
If your browser has information that the site enabled HSTS, the continue option isn't available ... that's what you need the cheat code for.
anonymousiam · 5h ago
100%!
TLS is fragile, and working around it is often necessary. Certs can expire or be revoked (anywhere in the chain) and the renewal process can be bugged. The time on the client (required for confirmation of certificate validity window) could be wrong (either accidentally or deliberately).
Requiring TLS on an inter-LAN connection is mostly useless, and impossible if no Internet gateway is available.
sgjohnson · 4h ago
> Requiring TLS on an inter-LAN connection is mostly useless, and impossible if no Internet gateway is available.
what do you mean?
> Requiring TLS on an inter-LAN connection is mostly useless
there are many ways to intercept inter-LAN traffic, and:
> and impossible if no Internet gateway is available.
DNS validation? Run your own CA and trust it in your intranet?
tgsovlerkhgsel · 2h ago
It really is unsafe though, even beyond what many who generally understand the web may realize. There are various ways (from caches to more obscure ones) in which loading a web site insecurely once, even if you aren't logged in at that time, can affect you much later when you think you are safe.
If you ever do this, use a separate browser profile or incognito window. Don't use this just to e.g. get to a captive portal (use example.com or neverssl.com for that).
You only need the "cheat code" if the site is using HSTS, which suggests it's the production web site of something that has a reason to try to be secure. If you're in a separate dev envrionment (different origin), you probably won't have HSTS set.
For local development or browser-to-local-app communication, localhost counts as a secure origin even without HTTPS.
sigio · 6h ago
I've been using this a lot (when testing), but I wish firefox/mozilla had something equivalent, because with HSTS domains, it's hard to bypass cert issues in firefox.
zzo38computer · 4h ago
In Firefox, I used a hex editor to modify the files so that it does not recognize the headers to set HSTS, and then I changed the file permissions so that the HSTS file cannot be modified, and then I disabled the HSTS preload list.
It's possible they changed it from "thisisunsafe" to the b64 version to avoid automatic scanners finding "unsafe" keyword usage.
tech234a · 4h ago
I've found this useful periodically on desktop but I wonder how/if it would work on mobile if you don't have a physical keyboard attached.
_def · 6h ago
I wonder if this is for quicker testing that happens recurringly (either automated or a poor soul doing it manually) where letting the phrase type by script is just easier than doing the 2 mouse clicks
pupppet · 3h ago
Hey Chrome, give us a cheat code to permanently hide the close buttons on tabs.
pyrolistical · 6h ago
Is this easier for screen readers to bypass?
almostgotcaught · 6h ago
Jesus Christ thank god for this! Recently libgen ceased to be accessible because of this and I couldn't figure out any way to disable (on Firefox as well!). Bless you.
miloignis · 5h ago
For Firefox, I can normally click Advanced -> Accept Risk and Continue, which I think is about the perfect amount of friction.
chatmasta · 6h ago
Well hopefully the blog doesn’t get too much visibility or they’ll change the string again :)
Sounds like the right place to look is the chromium commit log…
molticrystal · 5h ago
If an explicit keypress sequence becomes unavailable or changes, the script appears to call certificateErrorPageController.proceed(). So here is a bookmarklet that replicates this, add it to the URL field of a bookmark and click the bookmark to run it:
It should work as long as the proceed command remains functional and certificateErrorPageController hasn’t been renamed in non-developer builds.
giingyui · 5h ago
Hey at least Chrome lets you can bypass SSL errors. Firefox makes it impossible to bypass SSL errors if the site uses HSTS. So much for the browser for power users.
jeroenhd · 4h ago
Firefox sticks to the spec, Chrome makes you type out base64 manually to ignore the spec.
The TLS errors that aren't unbypassible by specification (i.e. HSTS, see https://datatracker.ietf.org/doc/html/rfc6797) can be bypassed on Firefox just fine. It's only the ones where the spec says bypassing the error shouldn't be possible where Firefox takes a hard stance.
Chrome had to alter their bypass string several times because vendors documented the override rather than fixing their insecure crapware. It makes total sense to me that Firefox does the same.
Dylan16807 · 4h ago
Being a user agent is more important than any spec.
sugarpimpdorsey · 4h ago
My installation of Firefox defaults to plain HTTP when I type a URL into the address bar. No amount of about:config fiddling seems to turn it off.
It is rubbish software, the developers routinely ignore fixing actual bugs in favor of new features, and I wish we had a better alternative that wasn't married to Google.
giingyui · 4h ago
Software should do what I want it to, not stick to a spec.
zzo38computer · 4h ago
I agree that it should do what you entered. However, it would make sense for the default settings to match the specification, unless the specification is no good (which, in the case of HSTS (and many other things in WWW), I do think the specification is no good).
giancarlostoro · 4h ago
Ah yes, software should leak everyone else's credentials to me because I want it to, forget keeping their information safe and secure, forget the GDRP.
yjftsjthsd-h · 4h ago
Nobody said that. If you tell your software on your machine to leak your credentials, then yes it should. And since it's your data and you're the one telling it to do it, I'm reasonably confident that gdpr says that's completely above board. (Like, I'm no lawyer so take with appropriate grain of salt, but it's generally described as saying that you have to have user permission to do things with data, which the user agent acting on your orders very much does have.)
wasmperson · 5h ago
An example for anyone who hasn't seen this before:
If it says the certificate for your bank is expired, you need to stop. If it says the certificate for the 10 year old public blog post that was linked by a 5 year old Reddit post as describing the solution to your problem, that should not matter, and you just want to read the non-secret contents of whatever is on that page regardless of whether the site's maintainer turned on HTTP to HTTPS redirects and then neglected to renew the certificate.
And people understand this, and people are rightfully going to devise workarounds for the second case, and it's ridiculous to expect them to not.
Non-HTTPS pages can be tampered with to inject any content into them e.g. into a blog post page, you could inject a login form ("sign in via Google to unlock this post"), a donation payment form ("donate for more content like this!"), or malware installers ("your browser is out of date, click to update" banner).
I think pushing to protect non-tech savvy users makes sense here. I see even a lot of developers not understanding risks like the above, so it's a losing battle thinking non-techy users can be educated about it and be cautious enough.
Who cares? The blog author could be malicious. The blog might have been sold 5 years ago and now hosts malicious content.
Stop trying to nanny people, it's unbecoming.
> People who care about the success of the web care because it makes the web more risky than people using mobile apps.
The main comparison here is whether a middleman injected it or the blog inserted it server-side. The level of risk is similar either way.
> The blog owner cares about the reputational hit.
If the blog hasn't been updated in ages, they probably don't.
There is still risk, but this is a form of risk which is not neccessary and can be reduced.
>If the blog hasn't been updated in ages, they probably don't.
We are talking about blogs that don't use https because they don't sell things. Expired certificates are out of scope of this comment thread.
It reduces it a little bit. But if you drop the risk of a random site being malicious by 25% that's not a very important change. The user still has to be wary. That reduction is not worth anything as drastic as blocking the site.
> We are talking about blogs that don't use https because they don't sell things. Expired certificates are out of scope of this comment thread.
I don't think we are?
"If it says the certificate for your bank is expired, you need to stop. If it says the certificate for the 10 year old public blog post that was linked by a 5 year old Reddit post as describing the solution to your problem, that should not matter, and you just want to read the non-secret contents of whatever is on that page regardless of whether the site's maintainer turned on HTTP to HTTPS redirects and then neglected to renew the certificate."
Doing that is stupid whether it's http or valid https or broken https.
And the whole point of this thread is that some sites have 0 reputation to hijack.
No I don't. At least not if it's recent. A certificate that expired in the last month is roughly equal in safety to a certificate that's valid for another month or two.
Expiration is a backup safety measure and the risk is mostly based on how long it's been since the certificate was issued.
Unless any banks are going around leaking keys right after they expire for some weird reason?
Certificate validity is binary. either it all is, or it isn’t. this included “not before”
Whereas a certificate error on a disused blog is pretty much what you'd expect from a disused blog.
The exception is cases where the site operator has opted in to HSTS or similar to indicate their decision to rather disable access than allow insecure access.
I think.
So this is where the "cheat code" comes in handy:
https://revoked.badssl.com/
https://subdomain.preloaded-hsts.badssl.com/
https://pinning-test.badssl.com/
Then there are those which have no "cheat code" bypass, so you'd have to use some other method:
https://rc4.badssl.com/
TLS is fragile, and working around it is often necessary. Certs can expire or be revoked (anywhere in the chain) and the renewal process can be bugged. The time on the client (required for confirmation of certificate validity window) could be wrong (either accidentally or deliberately).
Requiring TLS on an inter-LAN connection is mostly useless, and impossible if no Internet gateway is available.
what do you mean?
> Requiring TLS on an inter-LAN connection is mostly useless
there are many ways to intercept inter-LAN traffic, and:
> and impossible if no Internet gateway is available.
DNS validation? Run your own CA and trust it in your intranet?
If you ever do this, use a separate browser profile or incognito window. Don't use this just to e.g. get to a captive portal (use example.com or neverssl.com for that).
You only need the "cheat code" if the site is using HSTS, which suggests it's the production web site of something that has a reason to try to be secure. If you're in a separate dev envrionment (different origin), you probably won't have HSTS set.
For local development or browser-to-local-app communication, localhost counts as a secure origin even without HTTPS.
Sounds like the right place to look is the chromium commit log…
The TLS errors that aren't unbypassible by specification (i.e. HSTS, see https://datatracker.ietf.org/doc/html/rfc6797) can be bypassed on Firefox just fine. It's only the ones where the spec says bypassing the error shouldn't be possible where Firefox takes a hard stance.
Chrome had to alter their bypass string several times because vendors documented the override rather than fixing their insecure crapware. It makes total sense to me that Firefox does the same.
It is rubbish software, the developers routinely ignore fixing actual bugs in favor of new features, and I wish we had a better alternative that wasn't married to Google.
https://subdomain.preloaded-hsts.badssl.com/