Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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 generally at our add-on security architecture to make sure that it’s enforcing the right security properties at the least risk of breakage". I hope they'll be looking at that point here; if they want to support explicit revocation, there may be other ways to do it which aren't quite so prone to invocation by accident (e.g., publishing a revocation list signed by certs valid at the time of revocation).



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.”


Per the article, there is a separate "end-entity" certificate for each add-on. They were all signed by the same "intermediate" CA, however.


> They were all signed by the same "intermediate" CA, however.

And the expiration of that "intermediate" obviously should have not made already accepted add-ons stop working, in this specific use-case. It's not about establishing a new trusted communication channel for a new content, it's not about disabling some specific add-on.

Thinking logically, that was not the role of that immediate certificate.

So the behavior was clearly designed wrong, because completely wrong analogy was used -- that of creating a connection, where expired intermediate certificate should prevent the new connection, which could an transfer a new attack if not verified. Here the verification already happened, and the "ban" of a specific set of add-ons was also clearly not a case.

Additionally it seems the handling of the update of the expired intermediate was not the topic of the design at all.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: