Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Technical Details on the Recent Firefox Add-On Outage

hacks.mozilla.org

Post reply on HN
Print view View original

231–240 of 279 posts

Re: Technical Details on the Recent Firefox Add-On Outage

#231

Post by SeanDav »

brokenmachine wrote: post #141
DangerousPie wrote: post #51

My point of view as a long-time Firefox user that cares about privacy but also knows we live in an imperfect world: It obviously sucks that this happened but I think they handled it very well. The bug was fixed so quickly that I wouldn't even have realized it had happened if it hadn't been for the thread here on HN. My extensions hadn't even been disabled yet by the time the patch came out. And pushing out the hotfix…

I had a totally different experience. I'm still running FF 56.0.2 because I can't live without Tab Mix Plus. The official line was to wait for the update but about:studies never came up with anything even after 24 hours of waiting and everyone was saying it was fixed but it wasn't for me, I presume because nobody cares about the refugees stuck on pre-add-on breaking versions. So it was completely broken until I final…

I too am a Tab Mix Plus fan. I was using an ESR version to try to maintain better security while still using my favourite add-on. Now seemingly not possible. I am quite prepared to put up with security vulnerabilities for my personal use of browsers. I use sandboxing/ firewalls / VM's to protect myself. Not happy that an older version of Firefox was broken. I don't expect a company to maintain older versions forever, I do expect them to not deliberately or accidentally break them.

Give me back my Tab Mix Plus!

Re: Technical Details on the Recent Firefox Add-On Outage

#232

Post by acqq »

ddalex wrote: post #217
rst wrote: post #41

Earlier quoted context omitted.

I share the confusion. I can understand wanting to re-check addon validity somehow to allow for recalls on malicious addons that somehow slipped through. But I'm not sure what threat is mitigated by allowing a recheck to fail just because the clock has advanced, if all the certs were valid at the time of the installation. (Unless placing time bombs is the actual intent?) The post did say that they'll "be looking more…

The idea here may be to invalidate certain add-ons after they have been released in the wild by revoking the certificates used to sign them.

Only one certificate was used for all add-ons, its expiration disabled all signed. No “certain add-ons” it was “all.”

Re: Technical Details on the Recent Firefox Add-On Outage

#233

Post by StavrosK »

cortesoft wrote: post #149
StavrosK wrote: post #79

Earlier quoted context omitted.

Can you explain why you need the current time anywhere in this? Say I download a ten-year-old addon, it's signed by a valid signature from that root, with a valid signing date. What's the problem? Are we worried that someone will steal an old/expired cert and have control over a user's clock?

Imagine you have an old expired key... you take your new malicious extension, and sign it with the expired key and a time stamp that says it was signed at a time the key was still valid. Without some other verification mechanism, you can't tell the difference between this and an actual signature signed when the key WAS valid

Oh, the developers are signing their own extensions? I wasn't aware how it worked and I was missing that part, I thought Mozilla signed them on upload (and thus could trust itself to not be malicious).

Re: Technical Details on the Recent Firefox Add-On Outage

#235

Post by tinus_hn »

michaelt wrote: post #226
tinus_hn wrote: post #219

Earlier quoted context omitted.

How can you tel an app has actually been signed in the past? It could just as well been signed today with a fake date. This defeats the purpose of expiry. You could just as well have certificates that never expire and just start signing with a new one if you feel like it. Note the Mozilla ‘solution’ has the same problem: their root now authorized a new certificate with the old public key. If the original expectation…

It could just as well been signed today with a fake date. The traditional option (used by things like Java and ActiveX since the early 2000s) is Trusted Timestamping [1], where a trusted third party provides a signature (such as via RFC 3161 Time Stamp Protocol). AFAIK every certificate authority that sells code-signing certificates also provides a free timestamping server. If you trust a CA to issue code-signing cer…

You don’t trust an authority, you trust a private key that matches a public key you know. The point is that as time marches on the key might leak or be cracked and then your trust is misplaced. So you say the key pair expires and you stop trusting it before that happens.

This trusted timestamping relies on the same signing things with public and private keys process so it just adds a step, it doesn’t solve the problem. The timestamping key needs to expire as well and then it can’t be trusted anymore.

Re: Technical Details on the Recent Firefox Add-On Outage

#236

Post by cyborgx7 »

> We clearly need to adjust our processes both to make this and similar incidents it less likely to happen and to make them easier to fix.

I knew it. They are going to use THEIR fuck-up to justify why they need even more remote control and access to firefox installed on users machines.

Re: Technical Details on the Recent Firefox Add-On Outage

#237

Post by worble »

Twirrim wrote: post #90
DangerousPie wrote: post #51

My point of view as a long-time Firefox user that cares about privacy but also knows we live in an imperfect world: It obviously sucks that this happened but I think they handled it very well. The bug was fixed so quickly that I wouldn't even have realized it had happened if it hadn't been for the thread here on HN. My extensions hadn't even been disabled yet by the time the patch came out. And pushing out the hotfix…

I find it hard to marry up "Firefox user that cares about privacy" with being happy about the study mechanism. Don't you, from a privacy perspective, find it more than a little disturbing that the study mechanism has so much access to internal APIs in Firefox that it can install certificates without your involvement? That seems like a crazy security risk, let alone privacy risk. It's built in and enabled _by default_…

If you're using Firefox, and don't trust them not to collect data you don't want them to, then some "study mechanism" on/off switch isn't going to stop them.

If you don't trust them at least a little bit, you shouldn't be using their software full stop.

Re: Technical Details on the Recent Firefox Add-On Outage

#238

Post by pbhjpbhj »

Vinnl wrote: post #223
Silhouette wrote: post #132

Earlier quoted context omitted.

FWIW, I was genuinely shocked that this could happen, and it has severely damaged my trust in Firefox. I am extremely wary, having been bitten more than once, about software that automatically updates itself or is otherwise subject to remote interference. I don't run Windows 10. I don't use Chrome for anything important. I avoid subscription-based or activation-required software as much as possible. And in Firefox, I…

> I find the argument that it's impossible to make this configurable because malware could then circumvent it very weak. If we're talking about that level of interference, anyone with access to the Firefox executable could in theory replace it, and given the open source nature of the Firefox codebase this wouldn't be particularly difficult technically for anyone willing to go to such lengths in the first place. As me…

In reality the issue of Fortune 500 companies attacking users and hacking their computers should be addressed legally too.

Are Mozilla currently helping any organisations to sue these companies?

Is there more detailed evidence provided on this somewhere? Like which companies and exactly what they did?

Re: Technical Details on the Recent Firefox Add-On Outage

#239

Post by cyborgx7 »

cyphar wrote: post #174
username223 wrote: post #133

Earlier quoted context omitted.

"I'm sorry that you felt like you were..." is the worst form of apology, because it admits no guilt or responsibility. "I'm sorry that you were..." or "I'm sorry that we..." would be a legitimate apology. That said, nuking this data is the first good thing Mozilla has done in this whole fiasco. It's a small but real act of contrition, so kudos for that.

> "I'm sorry that you felt like you were..." is the worst form of apology, because it admits no guilt or responsibility. "I'm sorry that you were..." or "I'm sorry that we..." would be a legitimate apology. GP used the word "felt" and was expressing that he felt a certain way about enabling Studies. You're nit-picking a conversation and it has gone like this: A: I felt that $x. B: I'm sorry that you felt that $x. C:…

It is an insincere apology though, because it apologizes for something "you" are doing and not something "I" am doing. An acceptable way to apologize to "I felt that..." is "I'm sorry I made you feel like...".

And that's the minimum. Anything less than that is shifting the blame.

Post reply on HN