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

201–210 of 279 posts

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

#201

Post by brokenmachine »

phist_mcgee wrote: post #189
brokenmachine wrote: post #160

Earlier quoted context omitted.

Well I've just been educated on a new mechanism by which things can be remotely broken.

What did you expect to happen? You're using an online service connected to signing authorities. Of course it can be remotely broken at any time, that's how the internet works, it's all remote.

> What did you expect to happen?

Not this? I didn't think things would break with updates disabled.

Like I said, now I've been educated on a new mechanism for things to break.

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

#202

Post by semi-extrinsic »

simias wrote: post #78
contravariant wrote: post #72

Earlier quoted context omitted.

Maybe I'm jumping the gun here, but doesn't is seem that this kind of problem is exactly the kind of problem where a blockchain solution would be useful? Or at least more useful than the 'when all you have is a hammer' style applications of blockchains.

Given that you have a clear authority here (Mozilla) I don't see why you'd query a blockchain instead of querying signatures.mozilla.org As always Blockchains are a good solution only for a tiny group of problems.

> As always Blockchains are a good solution only for a tiny group of problems.

Flowchart here: http://philippe.ameline.net/images/ShouldYouUseBlckchn.jpg

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

#203

Post by BuckRogers »

driverdan wrote: post #180
Tsubasachan wrote: post #80

My heartfelt condolences to everyone who has had to browse the internet without an ad blocker. Nobody deserves that.

This is why you should have multi-tier defenses. An ad blocker in the browser, blackholed domains in your hosts file, and use DNS servers that also blackholes ad domains.

I used to do all 3 in the past, 4 with domain blocking done in router configuration, and am no longer a fan. It made troubleshooting any issue that may pop up too much of a hassle. Now I just use single-source blocking at the application layer. When Firefox disabled extensions, I simply used Edgium until they had it fixed.

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

#204

Post by looperhacks »

drtillberg wrote: post #148
Someone1234 wrote: post #75

Earlier quoted context omitted.

Agreed. My initial reaction when Let's Encrypt had you re-issue every 90 days was negative, but I was wrong. Very wrong. A 90 day re-issue forces you to have working re-issue infrastructure and procedures, and therefore you're less likely to get stung by an accidental expiration. Long expirations are a trap, a very easy trap to fall into.

Why not update long-duration keys every 90 days? That way you're never close to expiration, ever, best of both worlds.

In addition to what the other user said: if your certificate expires after a few years, it may take you a few years to notice it. And by then you probably don't know how you set up the not working process or don't even work at the company anymore.

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

#205

Post by josteink »

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

> sign it with the expired key and a time stamp that says it was signed at a time the key was still valid.

The whole point of a trusted timestamp is that such signature cannot be made for a fraudulent date, otherwise it would be utterly pointless.

This scenario and threat model does not exist if timestamping is correctly implemented.

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

#206

Post by bscphil »

cyphar wrote: post #168
drtillberg wrote: post #148

Earlier quoted context omitted.

Why not update long-duration keys every 90 days? That way you're never close to expiration, ever, best of both worlds.

Because if you make it optional then nobody does it (except you) and then you're back to square one. By mandating a 90-day expiry, LetsEncrypt forced people to automate the process -- and everyone is on the same page. It should be noted that most LetsEncrypt tools will renew a certificate when it is 30 days from expiry, so if you run the renew script every week (or day) you're also never close to expiry.

>By mandating a 90-day expiry, LetsEncrypt forced people to automate the process -- and everyone is on the same page.

Ironically, I had the opposite problem. I used to be on top of things like cert expirations, but now I just let certbot do everything. The problem (at least in my case) was that even though certbot updated the cert on time, it doesn't restart / reload nginx so that it picks up the new cert. My site was up for the full ~30 days between the renewal and the expiration of the old cert. So my site went down because of letsencrypt's cert renewal policy.

(I now have a script set up that reload's nginx's configuration whenever the certificate is updated.)

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

#207

Post by josteink »

PudgePacket wrote: post #195

> Note that this is the same logic we use for validating TLS certificates, so it’s relatively well understood code that we were able to leverage. Don't know whether to be happy or scared that the TLS validation code is "relatively well understood" :D ! I assume it's just a sub-optimal choice of phrasing.

I’m scared that they (still?) confuse regular HTTPS TLS-validation with code-signing.

These are two entirely different domains which follows entirely different rules.

Current Firefox behaviour is still broken, even after the “fix”.

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

#208

Post by bscphil »

silversconfused wrote: post #13

For anyone who misses the old days when a browser only did what you told it to, here is a solution: GNU icecat is a nice firefox esr fork with the mozilla call-home bits all turned off by default. It's very pleasant to use.

There's also GNU "abrowser", which (though terribly named) has the advantage of being based on the latest Firefox release rather than esr. It has the same privacy defaults as Icecat (though I believe it doesn't ship with the addons that Icecat does).

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

#210

Post by josteink »

johnp_ wrote: post #57
jzl wrote: post #11

Looks like a good read. I haven't finished reading it yet, but there's something I still don't get ... Windows and macOS both have a signing infrastructure for apps. The rules of that infrastructure dictate only that apps must have been signed by a valid certificate at the time they were signed. That way old app downloads don't need to be periodically re-signed just to account for expiring certificates. I can downloa…

It seems Mozilla is in the process[0] of moving the signature scheme to COSE, which allows timestamping[1]. A code comment[2] says that the current package format doesn't allow it. [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1545836 [1] https://tools.ietf.org/html/rfc8152#section-4.5 [2] https://searchfox.org/mozilla-central/rev/b9da45f63cb5672449...

If that is true, they should mention this in the post-mortem.

Code signing is a well understood problem with a well known solution, but the blog post discusses everything except the well known solution.

Right now you have a problem caused directly by lack of time stamping, and the article doesn’t even acknowledge that.

That’s not inspiring confidence. I’m genuinely still not sure if they have understood what the actual problem is and how to solve it properly.

Post reply on HN