What is shocking is that they still haven't found the way to properly fix it after 3 days.
I updated some SSL certificates last week (which even required contortions such as moving to a new issuer since some legacy software requires old-style SHA-1 signed ones which our current one doesn't provide), and it didn't take more than one (long) day of work.
At this point, changing out a cert takes me about 15 minutes (typically for multiple servers). 10 of those is figuring out the order in which to include intermediate certs. I really should script that part out.
The available web developers may not have access to either the SSL vendor or where the certificate is stored. None of the front-end devs I work with have access to either of those things.
I wonder if browsers should for (say) a week after a cert has expired, show an error so alarms are raised, but allow the dialog to be dismissed with an OK instead of all the "Confirm Security Exception" that would go on for a more serious cert rejection.
I think the real problem is that, by assuming users won't read error messages carefully, and making them shorter/less informative as a result, we've been implicitly encouraging this behaviour, leading to even less attention paid to the messages, etc. and the vicious cycle continues.
The original argument was that seeing error messages often will make users ignore them, but I don't think certificate errors should be very common now. Either way, I think we should be encouraging users to read error messages more carefully. Maybe the Yes/No buttons on the dialog should be put in a random order, and the question randomly flips between "Do you want to proceed?" and "Do you want to abort?"... adding a "learn more" option would be a good idea too.
I like this idea. At the moment there is nothing that differentiates a "this cert expired yesterday" warning from a "someone is MITMing your connection" warning, at least not for the casual user.
And since the former is (sadly) pretty common, this only teaches people that these warnings are not that unusual, and can safely be overridden.
It would be much better to have one "the server admin forgot to renew his certificate" type of warning and another "a totalitarian regime is trying to spy on you" type of warning...
Needs to work every few years for each domain. Unless all your certificates expire at the same time (or you only have a few), this will be triggered a few times per year.
And moreover, your scenario is essentially "worst case: fall back to previous behavior." That's not too bad...
That shouldn't be default behaviour in any browser but rather a plugin that you can install that gives the notification. Preferably with a whitelist of websites that I want to get notifications of.
Our website monitoring service https://t1mr.com will warn you before your certificate expires (in addition to warning you when your site is down, and giving you reports of inbound and outbound dead links).
If I understand right, getting a replacement cert doesn't result in a change of the private key anyways.
It's just magically, on the expiration date, your cert is somehow insecure and we must treat it as if YOU ARE IN DANGER!! - even though it's still better than then plain HTTP that everyone uses every single goddamned day. Hell, a self signed cert is better than plain HTTP, yet for some backwards-ass reason we treat it as worse, despite the fact it makes you immune from passive eavesdropping and any injection attacks, which the average person is a lot more likely to run into than a self-signed cert being used by an attacker to MITM you.
CA's are a scam and a racket. I can't wait for Mozilla's Let's Encrypt[1] to come along and put them all out of business, hopefully before the last decade or so of training users to ignore the wolf-crying cert warnings comes to fruition.
Yeah, this is irresponsible on Manjaro's part, they know the rules of the game, but the game is broken!
A "passive eavesdropper" has all the information they need to become an active man-in-the-middle. Observe the DNS query on its way out and send your own response with your IP before the real response comes back. The client will then make its TCP connection to that injected IP.
The DNS response doesn't have to come from the same channel as the original request. If you've got an ISP that doesn't check the source IP of what you're sending, your target's endpoint will see your fake response and treat it as the real one.
Where we stand now, the only thing stopping an eavesdropper from becoming a man-in-the-middle is the will and resources of that eavesdropper.
Self-signed can be worse because by the same token it can be MITM'd by another self-signed cert. It would create the false illusion of security, which could lead people to provide information they otherwise would not have.
With all due respect, how is that worse than HTTP? Plain HTTP can be MITMed just as well, only that on HTTP - except that no one would do that because for HTTP, plain old packet sniffing is enough to eavesdrop on a connection. Which doesn't work for self-signed HTTPS connections. And there are in fact a lot of common scenarios where it is easy for an attacker to sniff packets but harder to establish an MITM.
Because you'd never put your credit card into an HTTP web site, but you would on HTTPS.
Your argument about MITM being uncommon is moot because it's not impossible and is only rare because the current system is the way that it is. Changing the system would change the attackers' methods.
Then treat a self signed HTTPS cert as equivalent to an unsecured HTTP connection and be done with it.
There's absolutely no reason that the most common failure modes (expiration, bare domain vs www., self signed) presents warnings that Something Fishy Is Going On®, when 9999/10000 times, there is not.
Smoke coming from my neighbor's yard in the summer might be a fire, but in all likelihood, they're running a barbecue grill. The SSL equivalent would be calling the fire department every time someone puts some steaks on.
You can't treat a self-signed HTTPS cert as equivalent, because it has "https" in the URL, which people use to distinguish a safe connection from an unsafe one.
The issue is with HSTS. If you've visited the site before you've likely cached that SSL is required and your browser will refuse to connect. Using e.g. a 'private window' will allow it to be bypassed.
...and the fact that it kind of suggests that you might not want to trust a Linux distro to get security right on your boxes if they are unable to fix their SSL certs after 3 days.
With regards package updates, when Arch started publishing security update announcements Manjaro could start pushing those out faster. Delayed updates of other upstream packages is not really an issue (e.g. Ubuntu and CentOS have many packages that are not in sync with upstream).
By having an expiry, revoked certs can be forgotten about once the expiry has passed. We'd need to keep a forever growing list of revocations otherwise.
Also certs get switched to ones with stronger algorithms and longer keylengths after expiry. You also would have to revoke old certs all the time when their crypto isn't safe anymore.
