5 ms·

For the time stamp method to work, you need a trusted mechanism to attest that the timestamp is correct, otherwise the mechanism is useless (an attacker with an

For the time stamp method to work, you need a trusted mechanism to attest that the timestamp is correct, otherwise the mechanism is useless (an attacker with an outdated private key can just backdate the timestamp in the executable and then sign it). Windows code signing uses a server Microsoft runs to provide this, and Mozilla would need to do the same. I’m not saying they shouldn’t, but it is a significant piece of complexity.

reificator 7y ago
> Windows code signing uses a server Microsoft runs to provide this, and Mozilla would need to do the same. Mozilla already requires uploading even your private extensions to a Mozilla server to be signed for internal or external deployment. https://wiki.mozilla.org/Add-ons/Extension_Signing https://wiki.mozilla.org/Add-ons/Extension_Signing
jzl 7y ago
Ahh, right. Good point. I wonder then if the current system was a deliberate choice over the timestamp method, or just deemed easier to deal with on their end.
eps 7y ago
Every major CA runs a trusted timestamping service. Mozilla doesn't need to maintain their own timestamping infrastructure, they could delegate to one of the CAs, probably based on some sort of formal agreement with them. Though the way things stand, all CAs have no problem timestamping sigs made with certs that are from other CAs, so perhaps even no explicit agreement is required.
- temac 7y ago
  The checker just has to have roots tracing to timestamping CAs. I really don't understand why Mozilla designed their system like they did. Code signing is well known and probably even done for the Windows installer of Firefox, why did they just not duplicate the model? Checking expiration vs current time makes absolutely no sense for code signing, esp. at runtime (it could kind-of sort-of make a little bit of sense at install time, but I'm not really convinced, and maybe it is even not really possible to distinguish between the two with an effective boundary)
  - deleted 7y ago
    [deleted]
contravariant 7y ago
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.
- simias 7y ago
  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.
  - semi-extrinsic 7y ago
    > As always Blockchains are a good solution only for a tiny group of problems. Flowchart here: http://philippe.ameline.net/images/ShouldYouUseBlckchn.jpg http://philippe.ameline.net/images/ShouldYouUseBlckchn.jpg
StavrosK 7y ago
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?
- johncolanduoni 7y ago
  Not current time, but time of signing of the executable (not signing of the code sign certificate itself). If you (as the OP suggested) use time of signing instead of current time, the whole point is you’re not using the user’s clock anymore.
  - SAI_Peregrinus 7y ago
    Mozilla is already packaging the executable inside an archive. That archive contains the executable, manifest, and any other needed files. The signer can add a timestamp, either as a new file or as a part of the manifest. Then the timestamp is signed along with everything else, and can be checked for validity.
    - johncolanduoni 7y ago
      If all extensions are signed by Mozilla’s own certificate, then adding a timestamp won’t do anything for the reason I outlined above and they should just turn off expiration validation altogether. The time of code signing check is only useful if you want to trust one certificate (the developers) to sign things only within the duration noted in the cert, but are willing to trust another certificate (e.g. Microsoft’s timestamp cert) forever. If there’s only one certificate in play owned by the authority for the whole system, then there’s no point in the timestamp at all (for validation purposes).
- cortesoft 7y ago
  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
deleted 7y ago
[deleted]
Boulth 7y ago
> Windows code signing uses a server Microsoft runs to provide this, and Mozilla would need to do the same. Nope. Actually all CAs that offer code signing certificates are required to provide timestamping service compatible with RFC 3161. These timestamping servers are usually free to use, see for example https://knowledge.digicert.com/generalinformation/INFO4231.html https://knowledge.digicert.com/generalinformation/INFO4231.h...
Dylan16807 7y ago
It depends on the level of security you want. Let's say you compromise by letting old signatures stay valid, but only for a year. And you rotate the intermediate cert every 90 days. This system is more secure than the old one, because you only have to worry about key leaks for 15 months, instead of years. But at the same time, it's impossible to have this giant wave of everything failing at once. Instead the best case is nobody can sign extensions for a couple days, and the worst case is extensions that updated exactly a year ago start to fail in real time.

reificator 7y ago

> Windows code signing uses a server Microsoft runs to provide this, and Mozilla would need to do the same. Mozilla already requires uploading even your private extensions to a Mozilla server to be signed for internal or external deployment. https://wiki.mozilla.org/Add-ons/Extension_Signing https://wiki.mozilla.org/Add-ons/Extension_Signing

jzl 7y ago

Ahh, right. Good point. I wonder then if the current system was a deliberate choice over the timestamp method, or just deemed easier to deal with on their end.

eps 7y ago

Every major CA runs a trusted timestamping service. Mozilla doesn't need to maintain their own timestamping infrastructure, they could delegate to one of the CAs, probably based on some sort of formal agreement with them. Though the way things stand, all CAs have no problem timestamping sigs made with certs that are from other CAs, so perhaps even no explicit agreement is required.

temac 7y ago
The checker just has to have roots tracing to timestamping CAs. I really don't understand why Mozilla designed their system like they did. Code signing is well known and probably even done for the Windows installer of Firefox, why did they just not duplicate the model? Checking expiration vs current time makes absolutely no sense for code signing, esp. at runtime (it could kind-of sort-of make a little bit of sense at install time, but I'm not really convinced, and maybe it is even not really possible to distinguish between the two with an effective boundary)
- deleted 7y ago
  [deleted]

contravariant 7y ago

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.

simias 7y ago
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.
- semi-extrinsic 7y ago
  > As always Blockchains are a good solution only for a tiny group of problems. Flowchart here: http://philippe.ameline.net/images/ShouldYouUseBlckchn.jpg http://philippe.ameline.net/images/ShouldYouUseBlckchn.jpg

StavrosK 7y ago

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?

johncolanduoni 7y ago
Not current time, but time of signing of the executable (not signing of the code sign certificate itself). If you (as the OP suggested) use time of signing instead of current time, the whole point is you’re not using the user’s clock anymore.
- SAI_Peregrinus 7y ago
  Mozilla is already packaging the executable inside an archive. That archive contains the executable, manifest, and any other needed files. The signer can add a timestamp, either as a new file or as a part of the manifest. Then the timestamp is signed along with everything else, and can be checked for validity.
  - johncolanduoni 7y ago
    If all extensions are signed by Mozilla’s own certificate, then adding a timestamp won’t do anything for the reason I outlined above and they should just turn off expiration validation altogether. The time of code signing check is only useful if you want to trust one certificate (the developers) to sign things only within the duration noted in the cert, but are willing to trust another certificate (e.g. Microsoft’s timestamp cert) forever. If there’s only one certificate in play owned by the authority for the whole system, then there’s no point in the timestamp at all (for validation purposes).
cortesoft 7y ago
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

deleted 7y ago

[deleted]

Boulth 7y ago

> Windows code signing uses a server Microsoft runs to provide this, and Mozilla would need to do the same. Nope. Actually all CAs that offer code signing certificates are required to provide timestamping service compatible with RFC 3161. These timestamping servers are usually free to use, see for example https://knowledge.digicert.com/generalinformation/INFO4231.html https://knowledge.digicert.com/generalinformation/INFO4231.h...

Dylan16807 7y ago

It depends on the level of security you want. Let's say you compromise by letting old signatures stay valid, but only for a year. And you rotate the intermediate cert every 90 days. This system is more secure than the old one, because you only have to worry about key leaks for 15 months, instead of years. But at the same time, it's impossible to have this giant wave of everything failing at once. Instead the best case is nobody can sign extensions for a couple days, and the worst case is extensions that updated exactly a year ago start to fail in real time.