Live data from Hacker News

Let’s Encrypt DST Root CA X3 Expiration – September 2021

letsencrypt.org

11–20 of 72 posts

Re: Let’s Encrypt DST Root CA X3 Expiration – September 2021

#11
post #7
post #5

"In OpenSSL 1.0.x, a quirk in certificate verification means that even clients that trust ISRG Root X1 will fail" All current FIPS accredited devices use openssl 1.0.X, so the lets encrypt cross-signing hack will essentially break multiple corporate networks until the next openssl fips module is released at the end of this year. And could take another 6 months to make it into live systems

Isn't the point of FIPS accreditation that the organization wants to prioritize compliance over functionality/security? A FIPS device being unpatched or broken for a few months almost seems like the natural state of things, at this point.

My experience with HW HSMs has been that the FIPS process is so expensive that companies are only willing to put out a new FIPS-certified version once year. Also the certification itself seems to be more concerned with high-level security requirements rather than proof that any particular features of your HSM work correctly.

So the answer to any particular bug is typically wait until next year's version which includes all bug fixes that the normal releases have built up over the past year, or re-evaluate if you really need the certification.

Re: Let’s Encrypt DST Root CA X3 Expiration – September 2021

#12
post #7
post #5

"In OpenSSL 1.0.x, a quirk in certificate verification means that even clients that trust ISRG Root X1 will fail" All current FIPS accredited devices use openssl 1.0.X, so the lets encrypt cross-signing hack will essentially break multiple corporate networks until the next openssl fips module is released at the end of this year. And could take another 6 months to make it into live systems

Isn't the point of FIPS accreditation that the organization wants to prioritize compliance over functionality/security? A FIPS device being unpatched or broken for a few months almost seems like the natural state of things, at this point.

Yes, 100% this. The best evidence is probably that Dual_EC_DRBG got FIPS approval, but ChaCha20/Poly1305 and Curve25519 have not.

Re: Let’s Encrypt DST Root CA X3 Expiration – September 2021

#13
post #9
post #8

Earlier quoted context omitted.

Afaik what lets encrypt did is not a "hack" and perfectly valid. It sounds like users who have FIPS requirement need to fix it for their won use-case since its a bug in what they use and already fixed for everyone else.

Many enterprises use a FIPS SSL proxy for all employees web traffic, so all websites with these lets encrypt will effectively be invalidated if the proxies are using openssl FIPs modules, same for FIPS client side applications

It seems quite silly to me to enforce a massive MitM attack while at the same time sticking to the FIPS standards. Then again, a lot of governmental and financial security requirements are nonsensical to me, like mandatory password changes.

When I, as a website host, need to choose between accepting millions of Android devices or a few organizations with an esoteric security configuration, I'll go for the Android devices.

AFAIK Windows FIPS mode is unaffected by the OpenSSL bug, so not all FIPS modules will have trouble with the Let's Encrypt certificate. A Windows-based MitM-attack won't have this problem.

The best solution here would be for OpenSSL to have a FIPS release ready before September, or to release a patched version of 1.0.X, but that still won't help companies that cannot or will not update their software.

Re: Let’s Encrypt DST Root CA X3 Expiration – September 2021

#15

Is there another provider that could be an alternative to this? (zerossl maybe?)

Basically ZeroSSL and Buypass, yes. Buypass certificates have the additional benefit of being valid for 180 days. The rate limits are a bit stricter than with Let's Encrypt, I believe: https://www.buypass.com/ssl/resources/go-ssl-technical-speci...

Re: Let’s Encrypt DST Root CA X3 Expiration – September 2021

#16
post #6
post #3

Earlier quoted context omitted.

and a bad thing for e-waste.

Devices that can’t be updated all face an early ewaste destiny, don’t blame expiring certs.

well maybe a trust system that forces devices that can't be updated into obsolescence is not a good system.

Re: Let’s Encrypt DST Root CA X3 Expiration – September 2021

#17
post #16
post #6

Earlier quoted context omitted.

Devices that can’t be updated all face an early ewaste destiny, don’t blame expiring certs.

well maybe a trust system that forces devices that can't be updated into obsolescence is not a good system.

Maybe having devices that can't be updated is not a good system.

Re: Let’s Encrypt DST Root CA X3 Expiration – September 2021

#18
post #7
post #5

"In OpenSSL 1.0.x, a quirk in certificate verification means that even clients that trust ISRG Root X1 will fail" All current FIPS accredited devices use openssl 1.0.X, so the lets encrypt cross-signing hack will essentially break multiple corporate networks until the next openssl fips module is released at the end of this year. And could take another 6 months to make it into live systems

Isn't the point of FIPS accreditation that the organization wants to prioritize compliance over functionality/security? A FIPS device being unpatched or broken for a few months almost seems like the natural state of things, at this point.

It is. You can be secure or you can be FIPS-compliant, but not both.

Re: Let’s Encrypt DST Root CA X3 Expiration – September 2021

#19
post #3
post #2

At some point old devices that aren't receiving updates really need to go away, a good thing for security.

and a bad thing for e-waste.

To a point. The environmental footprint of a 486 tower system today would be much higher than modern system because the humans that use it more slowly and who have to maintain it use a lot more resources.

Re: Let’s Encrypt DST Root CA X3 Expiration – September 2021

#20
post #9
post #8

Earlier quoted context omitted.

Afaik what lets encrypt did is not a "hack" and perfectly valid. It sounds like users who have FIPS requirement need to fix it for their won use-case since its a bug in what they use and already fixed for everyone else.

Many enterprises use a FIPS SSL proxy for all employees web traffic, so all websites with these lets encrypt will effectively be invalidated if the proxies are using openssl FIPs modules, same for FIPS client side applications

I guess that will give them an incentive to fix those devices quickly.
Post reply on HN