Sounds like the right place to look is the chromium commit log…
javascript:(function(){if(window.certificateErrorPageController)window.certificateErrorPageController.proceed();})();
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.
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.
> 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 got the impression we were primarily talking about broken https. It's definitely not out of scope entirely:
"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."
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.
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.
I think.
So this is where the "cheat code" comes in handy:
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:
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?
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.
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.
eugenekolo•7h ago