3 ms·

> SSL certificate lifetimes are going down. Dates proposed. 45 days by 2027 45 days ? So much ? Why not expire the next day ?

by hulitu 2y ago

systemvoltage 2y ago
We need more safetyism culture. We need to ban root access completely by 2030. 10-factor security for login. 256 digit OTP and you must insert a drop of blood to login. At least, we’ll be super secure!
- redrove 2y ago
  Gotta think of the children! Children shouldn't root! ǝʞoɾ ǝᴉzzo uɐ s,ʇɐɥʇ sǝʎ
- xxs 2y ago
  >drop of blood... so cool, if there was some startup to give you a full health info with that. Imagine - with your login attempt it comes a proper analysis if you are fit for purpose.
  - systemvoltage 2y ago
    :-D Nice. The future we deserve. Now only if there was a company that was into one drop blood testing!
- LinuxBender 2y ago
  If we're going this route then maybe drop HTTPS all together, go back to port 80 and instead PGP encrypt each file with a different key and add the cool peoples public keys. This would keep malicious people and bots away from the content.
Y_Y 2y ago
For extra security I always use already expired certs.
- bravetraveler 2y ago
  Show the certs who is boss, revoke them on issuance
Etheryte 2y ago
Generate a new certificate for your connection for every round trip.
bawolff 2y ago
You are being downvoted, but it is a reasonable question. If you can renew every 45 days, why not every, say, 3 days? OSCP stapling except without the oscp stapling part.
- cm2187 2y ago
  And passwords expiring every 48 hours…
- ndsipa_pomu 2y ago
  3 days is far too short. The certificate supplier could have a crucial piece of equipment or software stop working and 3 days might be too tight a timeline to get it fully resolved which then leads to lots of people having invalid certificates and the certificate supplier would be out of business shortly afterwards.
- castillar76 2y ago
  There have been proposals about shortening much further: in fact, the long-standing practice in the PKI community is that renewing certificates every 7 days is short enough that no revocation service is necessary at all. However, trying to move the entire IT industry to a 7-day renewal window is a bridge too far at this point! Instead, I would surmise this is the first step in that process by introducing a window short enough to act as a forcing function on automating certificate issuance & renewal. It's short enough to strongly encourage leveraging automation everywhere possible, but not so short that one could argue it's impossible to do manually for things that still just can't do this automatically, of which there are still a disappointingly significant number. Once we begin to get below 30 days, however, I suspect there will be a lot more scrutiny around the data suggesting exactly how small a window is sufficient. From a risk standpoint, if we're arguing shorter-is-better, then we should go as short as possible: someone will need to pull together the data that suggest exactly how small a window appropriately balances the various risks involved. (And then 15 others will need to argue about the validity of the data, whether the data actually suggest that, whether the data were assembled with an agenda in mind, etc., etc., etc.).

> SSL certificate lifetimes are going down. Dates proposed. 45 days by 2027 45 days ? So much ? Why not expire the next day ?

by hulitu 2y ago

> SSL certificate lifetimes are going down. Dates proposed. 45 days by 2027 45 days ? So much ? Why not expire the next day ?

systemvoltage 2y ago

We need more safetyism culture. We need to ban root access completely by 2030. 10-factor security for login. 256 digit OTP and you must insert a drop of blood to login. At least, we’ll be super secure!

redrove 2y ago
Gotta think of the children! Children shouldn't root! ǝʞoɾ ǝᴉzzo uɐ s,ʇɐɥʇ sǝʎ
xxs 2y ago
>drop of blood... so cool, if there was some startup to give you a full health info with that. Imagine - with your login attempt it comes a proper analysis if you are fit for purpose.
- systemvoltage 2y ago
  :-D Nice. The future we deserve. Now only if there was a company that was into one drop blood testing!
LinuxBender 2y ago
If we're going this route then maybe drop HTTPS all together, go back to port 80 and instead PGP encrypt each file with a different key and add the cool peoples public keys. This would keep malicious people and bots away from the content.

Y_Y 2y ago

For extra security I always use already expired certs.

bravetraveler 2y ago
Show the certs who is boss, revoke them on issuance

Etheryte 2y ago

Generate a new certificate for your connection for every round trip.

bawolff 2y ago

You are being downvoted, but it is a reasonable question. If you can renew every 45 days, why not every, say, 3 days? OSCP stapling except without the oscp stapling part.

cm2187 2y ago
And passwords expiring every 48 hours…
ndsipa_pomu 2y ago
3 days is far too short. The certificate supplier could have a crucial piece of equipment or software stop working and 3 days might be too tight a timeline to get it fully resolved which then leads to lots of people having invalid certificates and the certificate supplier would be out of business shortly afterwards.
castillar76 2y ago
There have been proposals about shortening much further: in fact, the long-standing practice in the PKI community is that renewing certificates every 7 days is short enough that no revocation service is necessary at all. However, trying to move the entire IT industry to a 7-day renewal window is a bridge too far at this point! Instead, I would surmise this is the first step in that process by introducing a window short enough to act as a forcing function on automating certificate issuance & renewal. It's short enough to strongly encourage leveraging automation everywhere possible, but not so short that one could argue it's impossible to do manually for things that still just can't do this automatically, of which there are still a disappointingly significant number. Once we begin to get below 30 days, however, I suspect there will be a lot more scrutiny around the data suggesting exactly how small a window is sufficient. From a risk standpoint, if we're arguing shorter-is-better, then we should go as short as possible: someone will need to pull together the data that suggest exactly how small a window appropriately balances the various risks involved. (And then 15 others will need to argue about the validity of the data, whether the data actually suggest that, whether the data were assembled with an agenda in mind, etc., etc., etc.).