18 ms·

Certificates do not have to expire. This is all firmware handling 101, you put a public key in the software update function, and the updater checks any alleged

Certificates do not have to expire. This is all firmware handling 101, you put a public key in the software update function, and the updater checks any alleged update against that key, no dates involved.

chasil 3y ago
Actually, the OpenBSD people came up with "signify" which handles this more elegantly. FTP is still advertised for download of this OS, but any tampering or otherwise corrupted files will not pass a signature test when signify is invoked. The keys are rotated for every release, the next expected key is always included in the current OpenBSD release. This system would be safe to fetch sensitive content over cleartext http. EDIT: Here is a paper on signify: https://www.openbsd.org/papers/bsdcan-signify.html https://www.openbsd.org/papers/bsdcan-signify.html
- NohatCoder 3y ago
  Neat, but only really relevant for rolling updates. This feature is a one-shot installer.
- ilyt 3y ago
  Debian does that since forever. Release file also contains Date: Wed, 31 May 2023 14:13:10 UTC Valid-Until: Wed, 07 Jun 2023 14:13:10 UTC which allows spotting any tries of "downgrading" repository to previous version with potentially insecure packages Of course, you still have to get current time somehow but I guess once RTC is set the device can assume the changes in time won't be huge and just use any kind of https source for that.
asveikau 3y ago
But certificates expire for a reason, don't they? The idea is that with enough time, the key could be cracked.
- cerved 3y ago
  The reason is money. Sweet, delicious money
- allset_ 3y ago
  The more pressing reason they expire for web sites is that site ownership can change and you don't want someone else having an infinite lifetime cert for a domain you just bought. It's also useful to issue short lived certs and use the expiry date to handle revocation rather than maintaining a CRL.
- cortesoft 3y ago
  That isn’t why certs expire. If a hacker could crack the key in some time that is longer than the expiry but short enough to be a threat, they could instead just spend that time cracking the signing key that verifies the cert signature… then, the hacker could generate as many trusted certs as they want for for any domain.
  - oasisbob 3y ago
    That's exactly why SHA1 was deprecated in TLS certs. https://security.googleblog.com/2015/12/an-update-on-sha-1-certificates-in.html https://security.googleblog.com/2015/12/an-update-on-sha-1-c... Even OCSP was affected: https://cabforum.org/2022/01/26/ballot-sc53-sunset-for-sha-1-ocsp-signing/ https://cabforum.org/2022/01/26/ballot-sc53-sunset-for-sha-1...
    - cortesoft 3y ago
      I wasn't trying to say that brute force wasn't a risk, just that it wasn't why certainly expire
- AtNightWeCode 3y ago
  No.
  - AtNightWeCode 3y ago
koolba 3y ago
Doesn’t it do that with the firmware itself, i.e. verify that the firmware was signed by the manufacturer before updating? So the HTTP request leaks information about the update and could be MITM, but the result could at best be an older version? (Which could be a known exploitable one!)
- NohatCoder 3y ago
  If the description is to be believed, then no, they don't do that.
jameshart 3y ago
Right. But if you’re trying to establish an HTTPS connection to some server then that server’s cert is signed by some trusted root and THAT cert expires. Which is why it might be more future proof to embed your own non expiring cert and use an out-of-band signature verification for firmware rather than relying on being able to establish an HTTPS connection forever.
- deleted 3y ago
  [deleted]
- NohatCoder 3y ago
  Yes, that is what you should do. The problem is that they don't do that. No harm in also running HTTPS on top of that as you can renew the TLS certificate without issue.
- ilyt 3y ago
  At that point just use http + sigs. If you have working signature infrastructure you don't need encryption. There is some danger, attacker can see what you are getting, but that's far lower than "the update broke"

chasil 3y ago

Actually, the OpenBSD people came up with "signify" which handles this more elegantly. FTP is still advertised for download of this OS, but any tampering or otherwise corrupted files will not pass a signature test when signify is invoked. The keys are rotated for every release, the next expected key is always included in the current OpenBSD release. This system would be safe to fetch sensitive content over cleartext http. EDIT: Here is a paper on signify: https://www.openbsd.org/papers/bsdcan-signify.html https://www.openbsd.org/papers/bsdcan-signify.html

NohatCoder 3y ago
Neat, but only really relevant for rolling updates. This feature is a one-shot installer.
ilyt 3y ago
Debian does that since forever. Release file also contains Date: Wed, 31 May 2023 14:13:10 UTC Valid-Until: Wed, 07 Jun 2023 14:13:10 UTC which allows spotting any tries of "downgrading" repository to previous version with potentially insecure packages Of course, you still have to get current time somehow but I guess once RTC is set the device can assume the changes in time won't be huge and just use any kind of https source for that.

asveikau 3y ago

But certificates expire for a reason, don't they? The idea is that with enough time, the key could be cracked.

cerved 3y ago
The reason is money. Sweet, delicious money
allset_ 3y ago
The more pressing reason they expire for web sites is that site ownership can change and you don't want someone else having an infinite lifetime cert for a domain you just bought. It's also useful to issue short lived certs and use the expiry date to handle revocation rather than maintaining a CRL.
cortesoft 3y ago
That isn’t why certs expire. If a hacker could crack the key in some time that is longer than the expiry but short enough to be a threat, they could instead just spend that time cracking the signing key that verifies the cert signature… then, the hacker could generate as many trusted certs as they want for for any domain.
- oasisbob 3y ago
  That's exactly why SHA1 was deprecated in TLS certs. https://security.googleblog.com/2015/12/an-update-on-sha-1-certificates-in.html https://security.googleblog.com/2015/12/an-update-on-sha-1-c... Even OCSP was affected: https://cabforum.org/2022/01/26/ballot-sc53-sunset-for-sha-1-ocsp-signing/ https://cabforum.org/2022/01/26/ballot-sc53-sunset-for-sha-1...
  - cortesoft 3y ago
    I wasn't trying to say that brute force wasn't a risk, just that it wasn't why certainly expire
AtNightWeCode 3y ago
No.
- AtNightWeCode 3y ago

koolba 3y ago

Doesn’t it do that with the firmware itself, i.e. verify that the firmware was signed by the manufacturer before updating? So the HTTP request leaks information about the update and could be MITM, but the result could at best be an older version? (Which could be a known exploitable one!)

NohatCoder 3y ago
If the description is to be believed, then no, they don't do that.

jameshart 3y ago

Right. But if you’re trying to establish an HTTPS connection to some server then that server’s cert is signed by some trusted root and THAT cert expires. Which is why it might be more future proof to embed your own non expiring cert and use an out-of-band signature verification for firmware rather than relying on being able to establish an HTTPS connection forever.

deleted 3y ago
[deleted]
NohatCoder 3y ago
Yes, that is what you should do. The problem is that they don't do that. No harm in also running HTTPS on top of that as you can renew the TLS certificate without issue.
ilyt 3y ago
At that point just use http + sigs. If you have working signature infrastructure you don't need encryption. There is some danger, attacker can see what you are getting, but that's far lower than "the update broke"