Whether it was a good idea to limit those functionalities to a secure context or not, I don't know. I'm also a bit opposed to this forced HTTPS everywhere mentality.
[1] https://developer.mozilla.org/en-US/docs/Web/Security/Secure...
It would be less shameful to have it than an expired certificate. But most of all, anyone handling the site would have an advance warning, instead of a catastrophic failure. This would lower the number of actual expirations significantly.
That way, people who know (or should know) what these sorts of warnings mean will see them without ordinary users getting unnecessarily scared or confused. Hopefully a site's own developers regularly view their own site in the same browser they've used in the past for debugging the site.
the failure then, the same.
wondered although if there is some use in knowing an upcoming expiration.
# curl + GNU date + GNU grep -P
$ echo "cert days left: ~$(( ($(date +%s -d "$(curl -IvsS https://www.w3.org 2>&1 >/dev/null | grep -Po '(?<=^\* expire date: ).*')")-$(date +%s))/86400 ))"
cert days left: ~396
It’s the easiest outage to avoid because the moment the cert is generated, you know the exact time it will expire.
Imagine you can't use your banking site because the certificate expired a few minutes ago and the browser displays a (unnecessarily dramatic) error message. Not everyone is tech savvy enough to ignore those messages.
The browsers already let you visit the site if you want to, so I don't think there is a big deal.
Also, CAs might not revoke expired certificates any more, as they are already expired, which hurts security as well if there is a reason to revoke the certificate, but no means to do so.
With an extension, this feature can be introduced gently, without risking any security issues.
Sure a recently expired cert is pronably the least severe issue a tls cert can have, but still - expired certs that are compromised usually aren't revoked. If i'm visiting my bank, i definitely want things to err on the side of not working.
https://www.infoworld.com/article/2925839/code-injection-new...
https://www.privateinternetaccess.com/blog/comcast-still-use...
https://blog.avast.com/mikrotik-routers-targeted-by-cryptomi...
This is not particularly hard. Most static hosting services even do it for you.
I tried to remove a specific cookie from my browser session recently. The only way is to go into Developer Tools, find what tab has "Storage", find the cookies, select the cookie you want, right click and delete it. You can't do it from the 4 other user-friendly screens that already show you the individual cookies, because why would a user ever want to delete an individual cookie?
I think this is the same reason for all of the poor browser UX over the years, like personal certs. The web would be a lot more secure if personal certs had supplanted passwords 15 years ago. But then we'd have to build something other than a single pop-up box to manage them.
Sure, we got a built-in password manager, and we suggest random passwords for users, and save them locally, and the user needs to back them up (or reset them via e-mail). But doing the same thing for certificates might be confusing, meaning, somebody would have to actually talk to a user (until it became common knowledge). Better to wait for something way more complicated and expensive to show up, and ignore UX there too. (https://security.stackexchange.com/questions/1430/is-anybody...)
In a world where users rarely see their actual passwords, it's much less of a UI change to (nearly) silently replace password changes with certificate signings and (nearly) silently replace password logins with certificate presentations. A small extra attribute in the HTML input tag could signal to the password manager that it should perform the certificate workflow instead of the password workflow.
Ideally, instead of specifying a specific mechanism, the extra input tag attribute would signal the password manager to actually perform a SPNEGO mechanism negotiation, so the password manager and the server could negotiate if they were using certificates, Kerberos, or some future mechanism. Though, this would also require adding certificate support to GSSAPI. The upside would be that future changes could be done without any changes to HTML.
For example, the fact you are reading the wikipedia article on Tiananmen square incident might be very sensitive if you live in China (ignoring the part where they block wikipedia). Other places might object to various other speech, etc.
Although to be fair, the mass survelience threat model is probably less likely to have an active attack like tls stripping. But annonoyminity is all about hiding in the crowd; only securing the connection when you have something to hide from eavesdroppers means that you have no crowd to hide in when you need to.
Again, I am not advocating for not having HTTPS so I don't know why you think HTTP+HTTPS is less private. It is exactly as private only it is also human readable and requires no centralized authority's lease to be visitable.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/St...
> curl -sSk -D- https://cryptome.org/ -o /dev/null | grep strict-transport-security
strict-transport-security: max-age=31536000
Proceed to cryptome.org (unsafe)
At work we use Chrome as our general browser, and we've had several issues with expired certs before. Some websites allowed you to expand the box and opt "Continue" but some simply didn't have the option. Whats the difference?
The assumption is "must be very wrong" is an attack you don't want people to "continue" past. Occasionally it bites back like this if you don't maintain your certificates.
Offering HTTP transport invites attackers to inject advertisements, malware, or viruses into your packet stream. ISP like comcast and ATT are notorious for doing this.
Allowing falsified or expired certificates invites attackers as well.
HTST This is a good thing.