SoylentNews is people
SoylentNews
from the what-browser-will-you-use-to-read-the-report? dept.
Eric Rescorla has a blog post over at Mozilla about the technical details on the recent Firefox add-on outage. He covers the background of how they use certificates, how they tried to mitigate the damage from the outage, how they worked to solve the problem without breaking more things, deployment of the replacement certificate, and why it took so long to fix.
Recently, Firefox had an incident in which most add-ons stopped working. This was due to an error on our end: we let one of the certificates used to sign add-ons expire which had the effect of disabling the vast majority of add-ons. Now that we've fixed the problem for most users and most people's add-ons are restored, I wanted to walk through the details of what happened, why, and how we repaired it.
There were a lot of work arounds discussed here and elsewhere, some of them quite stupid so, lastly, remember to undo any temporary work-arounds that might have been deployed last weekend.
Earlier on SN: In Firefox All Extensions Disabled Due to Expiration of Intermediate Signing Cert
(Score: 5, Interesting) by bzipitidoo on Saturday May 11 2019, @01:51AM (9 children)
I say the real problem is the practice of making certificates expire, how that's implemented, and the consequences that are imposed. The expiration is not graceful, it abruptly switches from working fine to broken. No warnings, no gradual degradation of functionality, not much of a failsafe. The users didn't do anything wrong, but they sure get punished and frightened.
The scary warning messages are way over the top, very much like the typical spam phishing email that warns your account and all your saved emails will be deleted unless you verify your password. The world is not going to end and you are not going to lose all your data just for visiting a web site with an expired cert, or because your computer's clock is off by several years. Very much like the Boy Who Cried Wolf, the false alarms undermine the credibility of the whole system. Why shouldn't the users just ignore the warnings?
Every time a mistake of this sort is made, it results in angry and frustrated users, and a very embarrassed group of engineers. And certificate mistakes happen shockingly often. This time it was Firefox's turn. Members of the group of large, tech savvy organizations that suffered an embarrassing cert expiration include IBM, Microsoft, and I think even Google. Wouldn't be at all surprising if most of the rest slipped at least once. That's not cause for laughing at them, that's evidence that the security system is messed up and ought to be changed.
(Score: 1, Insightful) by Anonymous Coward on Saturday May 11 2019, @02:15AM (5 children)
Just modded you up, interesting.
Three of us volunteer to run a website for mechanical engineering students, where the students can download some proprietary data that is useful for a specific engineering project. So far, we've stuck to http: for our small website. To get a login, the students have to prove they are from a member university that has joined our informal consortium--among other things there are arcane questions relating to this project. After manual vetting, we issue logins (a few a week, not a big deal).
We've resisted going to https: for reasons like you mention -- none of us are expert admins and the chance of us screwing up seems higher than any additional security from https:
Or maybe we are so amateur that we have missed the point altogether(grin)?
(Score: 3, Informative) by Arik on Saturday May 11 2019, @02:49AM (4 children)
If laughter is the best medicine, who are the best doctors?
(Score: 0) by Anonymous Coward on Saturday May 11 2019, @06:03AM
Even if it is they are still open to 0-day browser exploit insertions from their providers (which basically means government as well, one way or the other).
(Score: 1, Informative) by Anonymous Coward on Saturday May 11 2019, @06:24AM
if you dont care about verifying the identity of your website to the user and only want
to secure / encrypt the data exchange bit-stream then just use simple easy self-signed certs.
ofc the global players in the identity managment businesssss continue to lump both aspects together.
one could verify that one has indeed reached the genuine website both all data exchange is in the clear (so wat for some data, right?)
-or-
one is not sure one has connected to the genuine site but all data exchange to it is encrypted (self signed certs).
browser makers have to stop beating on the second because verifying a sites identity (genuine) COSTS MONEY!
a self signed cert (for encrypted data exchange) is FREE!
(Score: 0) by Anonymous Coward on Saturday May 11 2019, @04:42PM (1 child)
Seriously, what is the worst that could happen? If they know to use unique credentials (always a good idea regardless), it won't give an attacker access to anything else. "download some proprietary data", ok if this is multi-million dollar data that would be bad if it wound up in the wrong hands, then there might be an issue. But if it is run-of-the-mill crap from some manager's ass that they want to keep private just to make them feel good, then who cares?
(Score: 0) by Anonymous Coward on Saturday May 11 2019, @05:42PM
Yes, we use unique credentials -- one user (normally a university student) per login. We don't have any great way of keeping a student from sharing their login, except that we make it easy to have your own. For example, we can tell when a class has a project that requires our data--all of a sudden we get a small batch of requests for logins from one university.
The other thing we do is manually remove logins after a period of disuse, or after the student graduates. Over the last dozen years we've probably approved 4000 user names, but only 800 are active now. If anything, we err on being too aggressive when clearing out unused logins--if we delete a legit user by mistake, we apologize and tell them to apply again.
The data we distribute is measured by a specialized test lab that gives our informal group a special "student price" and, in exchange, asks that we try to restrict the data to academic use, no commercial use. After all, this test lab is in business and they expect commercial customers to pay regular rates. This is a handshake agreement, there are no legal repercussions if the data does "escape" to a company.
(Score: 0) by Anonymous Coward on Saturday May 11 2019, @11:51AM (2 children)
You can bet the next time this is about to happen the hackers will be ready and waiting to take advantage of the 5% of users using Firefox who won't be protected by plugins
(Score: 0) by Anonymous Coward on Saturday May 11 2019, @05:49PM (1 child)
> ...the hackers will be ready
What, you mean we FF users will start seeing ads again? Oh noes...
Or did you think of something more sinister that would be possible??
(Score: 0) by Anonymous Coward on Sunday May 12 2019, @08:03AM
Given this also affected torbrowser users the stakes are much higher.
Very sad this happened, again.