4 ms·
Could you explain why verifying on every startup, instead of just on install, is necessary? The page you linked doesn't mention it. Edit: Let me amend my quest
by deogeo 8y ago
Could you explain why verifying on every startup, instead of just on install, is necessary? The page you linked doesn't mention it.
Edit: Let me amend my question - why is it necessary for the certificates to expire? If a plugin is signed by Mozilla, why wouldn't it be trusted once it gets old?
- Xylakant 8y agoThere’s no guarantee that a (malicious or undesirable) extension was added via FF, so check on install could be circumvented by any of the crapware installers we all love.
- makomk 8y agoHow do you propose Firefox should tell whether the unsigned, shady add-on was installed by the user, or by some other dodgy app messing with Firefox's files whilst it wasn't running to make it look like the user installed the add-on?
- tzs 8y ago> Let me amend my question - why is it necessary for the certificates to expire? If a plugin is signed by Mozilla, why wouldn't it be trusted once it gets old? I asked essentially that question earlier, and received some good answers explaining why [1]. Briefly, if something is signed by an expired certificate, whether or not you can trust the signature depends on whether or not the signing took place while the certificate was not expired. If all you have is the thing and the signature from the code signer, you can't tell for sure when it was signed. If a bad guy has obtained an old signing certificate and its keys, that bad guy can generate new signatures that claim to have been signed while the certificate was valid. Some code signing systems, such as the one in Windows (and I think the one Apple uses) also use another certificate, from a timestamp service, to prevent this. The way a timestamp service works is you send them a hash of a document, and they generate a certificate signed by them that essentially says "We were shown this hash on this particular date/time". When you include the timestamp certificate with the signature from the code signer, then when you come across code that was signed by an expired certificate but purports to have been signed while the certificate was still valid, you can check the timestamp certificate to see if that is true. If it is, you can still consider the code signing to be valid. Forgetting to renew a signing certificate is still bad even if you do this, but not as bad. If Microsoft or Apple forget, it doesn't stop existing applications from working, so end users aren't immediately impacted. It does stop developers from shipping updates or new applications, so still would be a big deal. I could see a bad guy noticing that a company always updates expiring certificates one month in advance, say, and then noticing that a certificate is expiring in just a week, infer that the certificate renewal has slipped through the cracks and is going to expire, and time the use of a critical zero day exploit to fall in the window when updates are broken by the expired certificate. [1] https://news.ycombinator.com/item?id=19824017 https://news.ycombinator.com/item?id=19824017
- DoctorOetker 8y agoI checked the hash functions for the xpi, its broken MD5 and broken SHA... which doesn't matter for a running instance if FF takes care to download it from their own servers over HTTPS... but in the attack model you describe it is retrieving the signatures from an untrusted disk. https://news.ycombinator.com/item?id=19830228 https://news.ycombinator.com/item?id=19830228