3 ms·

This is precisely like NIST requirements to change your password frequently, which was well intended, but reduced security due to people not being able to recal

by b112 1y ago

This is precisely like NIST requirements to change your password frequently, which was well intended, but reduced security due to people not being able to recall their password. (This is now reversed, of course) Reducing certificate life to ridiculous time frames, making it difficult to obtain certificates, all for very dubious, extremely tiny and minor improvements in security. It's going to cause more harm than good, and in the end, will reduce not enhance security. For example, many SMTP servers may revert to self-signed certs now.

Hilift 1y ago
47 days isn't ridiculous if it is automated.
- b112 1y ago
  It's fine to allow short time frames, so those that can and will automate are able. It's not fine to force it. There's no logic behind it. Browser and OS updates can expire certificate authorities, and that's the only real reason people claim this is to be done.
  - devmor 1y ago
    The logic behind it is to make the internet more onerous and annoying for individuals to have control over. The more active responsibility you must have in taking part in the internet, the more of that responsibility you will relinquish to the corporations that wish to control it.
  - fpoling 1y ago
    The automated setup makes it less likely that the private key leaks. That alones makes it a reasonable justification to shorten the validity timeframe to force automation. And then if a certificate authority knows that it’s certificate root can be disabled quickly, it puts more pressure on them to follow the rules. Of cause it means that those who still run setups where the certificate cannot be updated quickly will suffer. But then one still has option to run http.
    - b112 1y ago
      We have a single body deciding this, non-democratically. This isn't how RFCs used to work, how html used to be decided, how standards are crafted. The "big boys" aren't the standard setters of the older internet. For example, the more often you need to get a key, the more interactions you have where a leak may occur. If you get keys 36 times in 3 years, instead of once in 3 years, you're that many times more exposed. Further, automation provides many edge cases for non-human monitored issues to occur. A process that requires human intervention at least requires someone to see the process. Automation can be setup years ago, and people may not even realise it is occurring. That doesn't help security. At all. As I said, it's NIST forced password rotation all over again. Attempts to make things better, but the end result is worse. And of course Google thinks this is all grant. After all, in their eyes small mail servers, hobby mail servers, small orgs doing it on their own are a hassle. Everyone should just use gmail, yes?
      - fpoling 1y ago
        The web server needs access to the key to sign the reply so the key is accessed all the time. With automation LE style one typically creates an account with LE when one renews the key so there is no need to have an account password or similar which decreases the attack surface compared with any manual procedure. So while I agree that Google and friends have too much power, in this case the decision was reasonable.
  - bigbuppo 1y ago
    Well, the one good excuse for the short durations is that the two main mechanisms for certificate revocation don't actually work very well. In other words, these idiots that got us into this mess didn't understand how anything works. These same idiots are now making decisions that only make sense if everyone operates like Google. The real world does not operate like Google.
- bigfatkitten 1y ago
  It is if you need a certificate for a service that must be trusted by devices owned by members of the public, but which otherwise isn’t Internet connected. Entertainment systems on aircraft and vessels, for example.
  - throwaway7356 1y ago
    Aircraft are connected to the internet. So no problem there. Other vessels too.
    - bigfatkitten 1y ago
      Some are, most aren’t. These systems have extremely long operational lifecycles. Retrofitting aircraft with SATCOM terminals etc is not always possible or economically worthwhile.
arccy 1y ago
password expiry was bad only because humans were in the loop. otherwise, for secure things you rotate secrets every time, like new encryption keys for every tls exchange, and a continuous cycling of keys for perfect forward secrecy in e2e messengers.
hedora 1y ago
I completely agree. For many years, I've gotten the impression the SSL ecosystem is designed to undermine endpoint security. For instance, there were credible accusations that the NSA had a mole on the standardization committee back in the 90's. Their entire job was allegedly to promote things that increased implementation complexity and block things that simplified implementation. SSL client certs (which this change is yanking) are great for convenience and security (assuming you trust the CA). Frequently rotated certs lead to outages, and normalize needless credential rotations. If you believe your backend server is compromised, this is a good thing. However, in any scenario where you're achieving your security goals, that server isn't compromised (the data on it is probably more sensitive than the cert) and rotating the certificate frequently just makes it harder to detect a third party using a man-in-the-middle cert to transparently proxy it. Speaking of which: If you can momentarily control a DNS record or if you are a cloud provider that controls all network paths to your customers, then you can use Lets Encrypt (or any of the ACME providers) to generate a MITM certificate + transparently proxy traffic. For traffic I care about securing, I use things like wireguard or SSH trust on first use.

by b112 1y ago

Hilift 1y ago

47 days isn't ridiculous if it is automated.

b112 1y ago
It's fine to allow short time frames, so those that can and will automate are able. It's not fine to force it. There's no logic behind it. Browser and OS updates can expire certificate authorities, and that's the only real reason people claim this is to be done.
- devmor 1y ago
  The logic behind it is to make the internet more onerous and annoying for individuals to have control over. The more active responsibility you must have in taking part in the internet, the more of that responsibility you will relinquish to the corporations that wish to control it.
- fpoling 1y ago
  The automated setup makes it less likely that the private key leaks. That alones makes it a reasonable justification to shorten the validity timeframe to force automation. And then if a certificate authority knows that it’s certificate root can be disabled quickly, it puts more pressure on them to follow the rules. Of cause it means that those who still run setups where the certificate cannot be updated quickly will suffer. But then one still has option to run http.
  - b112 1y ago
    We have a single body deciding this, non-democratically. This isn't how RFCs used to work, how html used to be decided, how standards are crafted. The "big boys" aren't the standard setters of the older internet. For example, the more often you need to get a key, the more interactions you have where a leak may occur. If you get keys 36 times in 3 years, instead of once in 3 years, you're that many times more exposed. Further, automation provides many edge cases for non-human monitored issues to occur. A process that requires human intervention at least requires someone to see the process. Automation can be setup years ago, and people may not even realise it is occurring. That doesn't help security. At all. As I said, it's NIST forced password rotation all over again. Attempts to make things better, but the end result is worse. And of course Google thinks this is all grant. After all, in their eyes small mail servers, hobby mail servers, small orgs doing it on their own are a hassle. Everyone should just use gmail, yes?
    - fpoling 1y ago
      The web server needs access to the key to sign the reply so the key is accessed all the time. With automation LE style one typically creates an account with LE when one renews the key so there is no need to have an account password or similar which decreases the attack surface compared with any manual procedure. So while I agree that Google and friends have too much power, in this case the decision was reasonable.
- bigbuppo 1y ago
  Well, the one good excuse for the short durations is that the two main mechanisms for certificate revocation don't actually work very well. In other words, these idiots that got us into this mess didn't understand how anything works. These same idiots are now making decisions that only make sense if everyone operates like Google. The real world does not operate like Google.
bigfatkitten 1y ago
It is if you need a certificate for a service that must be trusted by devices owned by members of the public, but which otherwise isn’t Internet connected. Entertainment systems on aircraft and vessels, for example.
- throwaway7356 1y ago
  Aircraft are connected to the internet. So no problem there. Other vessels too.
  - bigfatkitten 1y ago
    Some are, most aren’t. These systems have extremely long operational lifecycles. Retrofitting aircraft with SATCOM terminals etc is not always possible or economically worthwhile.

arccy 1y ago

password expiry was bad only because humans were in the loop. otherwise, for secure things you rotate secrets every time, like new encryption keys for every tls exchange, and a continuous cycling of keys for perfect forward secrecy in e2e messengers.

hedora 1y ago

I completely agree. For many years, I've gotten the impression the SSL ecosystem is designed to undermine endpoint security. For instance, there were credible accusations that the NSA had a mole on the standardization committee back in the 90's. Their entire job was allegedly to promote things that increased implementation complexity and block things that simplified implementation. SSL client certs (which this change is yanking) are great for convenience and security (assuming you trust the CA). Frequently rotated certs lead to outages, and normalize needless credential rotations. If you believe your backend server is compromised, this is a good thing. However, in any scenario where you're achieving your security goals, that server isn't compromised (the data on it is probably more sensitive than the cert) and rotating the certificate frequently just makes it harder to detect a third party using a man-in-the-middle cert to transparently proxy it. Speaking of which: If you can momentarily control a DNS record or if you are a cloud provider that controls all network paths to your customers, then you can use Lets Encrypt (or any of the ACME providers) to generate a MITM certificate + transparently proxy traffic. For traffic I care about securing, I use things like wireguard or SSH trust on first use.