Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

letsencrypt.org

Post reply on HN
Print view View original

61–70 of 72 posts

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

#61

Post by tialaramex »

mrtesthah wrote: post #60
TonyTrapp wrote: post #50

Earlier quoted context omitted.

Doesn't macOS allow you to add new root certificates to its certificate store? If not, you could still use a browser that brings its own certificate store (e.g. Firefox). This is significantly different from locked-down or embedded IoT devices you have no control over.

Oh, I keep my computer up to date. It's everyone else's computer that needs to work with my Let's-Encrypt-certificate-using software that's the problem.

One small piece of good news for Let's Encrypt is that it's so common chances are even your most hardcore fans, who presumably first notice this issue on your site because they visit so often, will then also get the same problem on half a dozen other sites they visit.

This applies especially for the case where what goes wrong is exactly that the visitor doesn't trust ISRG and ceases to trust DST Root CA X3 when its self-signed root expires. A lot of other problems will bite those who get new certificates first, but this problem will bite every site with a Let's Encrypt certificate at essentially the same moment regardless.

So at least the blame will be spread around thinly and for most users there will be an overwhelming impression they need to actually do something on their side and not just moan and hope the problem goes away.

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

#62

Post by crazypython »

Aissen wrote: post #28
crazypython wrote: post #25

I wish Let's Encrypt had a plan to get cross-signed by a CA those older devices still trust.

Which devices ? They did find a solution for most Android devices, and it is now the default chain provided via ACME.

iPhone 4.

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

#63

Post by rsj_hn »

tux3 wrote: post #7
aisio wrote: 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.

That is a pretty skewed interpretation. FIPS mode does things for you like flag uses of the same private key for encryption and authentication, it prevents the use of weak keys, and prevents use of hobbyist or non-approved algorithms including some sketchy PRNGs. The executable signing also makes monkey-patching harder, so it's more difficult to hook into an implementation and compromise it without detecting this at the compilation stage. That can and does have real security benefits.

The downside of FIPS mode is that because the certification process is so costly and time consuming, it will generally run behind and not get the latest algorithms until a few years have passed. That type of conservatism in cryptography can be good or bad, but overall I'd rather use a FIPS system than not, given the large number of dubious systems in use, and the FIPS system will be more secure than the average non-FIPS system, but less secure than a non-FIPS system carefully reviewed by experts.

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

#64

Post by currysausage »

crazypython wrote: post #24
currysausage wrote: post #15

Earlier quoted context omitted.

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...

I assume they are more trusted by older devices than Let's Encrypt. Source?

Relevant for Apple OSs: https://support.apple.com/en-us/HT209143

"Buypass Class 3 Root CA", which appears to be the root certificate they currently use, is present for all listed iOS versions (7+), which seems like a good sign. Let's Encrypt's "ISRG Root X1" is present in iOS 10+.

Similar lists for Android would be wonderful but probably impossible to compile due to ecosystem fragmentation. I guess there is no caniuse.com for root certificates.

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

#65

Post by slownews45 »

alias_neo wrote: post #49
slownews45 wrote: post #42

Earlier quoted context omitted.

Mandatory 90 day password changes are still required by the IRS in the US at least. High complexity / weird rules too - and not one password across systems as they have endless DIFERRENT login systems. So your tax software itself will require 90 day resets for all staff using that, every interface to IRS requiring it (which means every login for little used systems). It's bonkers. My worry - how do they even correlat…

Ouch that sounds painful. If I'm not mistaken, all/most Americans have to interact with the IRS regularly? So this is an issue for many of you? By that I mean as a Brit who is salaried (PAYE) and doesn't own a business I have never had to interact directly with HMRC so even if it was as bad (it's not) it would be an infrequent experience.

This primarily affects professionals dealing with the IRS.

Individuals have been migrated a few times and a few different logins.

IRS had a "get transcript" service. It had things like super secure passwords and password rotations, but password reset and setup could be done with social security + some real basic info from credit reports (ie, where did you live etc) and didn't not timeout.

So think - 100's of thousands of fake accounts for the hackers, and pain for the real users.

That's pretty common in the US for govt systems - the password reset process is often ridiculously easy because some systems have so many reset requests you can't function with anything careful.

Imagine folks in govt - 10 systems, 90 day password rollover and there was a move for a while to 12 character passwords with no reuse and upper / lower / special / numbers (but special characters are limited so password generators often error out). It got so bad there was one reset process that was outsourced to a third party AND all you had to provide was the username which was derived from the users full name. They then gave you a new password over the phone. It was honestly easier to reset then even fight the system. You have a new intern whose forgotten their password, IT just calls reset help desk for a new one.

The security problems in all this are

1) reset process so weak

2) everyone - and I mean everyone, writes these passwords down in a text file on computer

3) because new account setup can be ridiculously long - a fair bit of password sharing, so these passwords tend to end up all over the place (training documents etc etc) which then of course end up online somewhere.

I could go on.

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

#66

Post by slownews45 »

benlivengood wrote: post #55
slownews45 wrote: post #42

Earlier quoted context omitted.

Mandatory 90 day password changes are still required by the IRS in the US at least. High complexity / weird rules too - and not one password across systems as they have endless DIFERRENT login systems. So your tax software itself will require 90 day resets for all staff using that, every interface to IRS requiring it (which means every login for little used systems). It's bonkers. My worry - how do they even correlat…

There are two risk classes; reused passwords exposed by a breach, and targeted attacks (phishing, dictionary/brute-force attacks, etc). The first is easiest to detect by finding password dumps and by observing login attempts. Targeted attacks are best prevented by 2FA. There never was any middle ground where password rotation improved security. For any high security systems worried about insider risk or espionage the…

My own view - reused passwords come from leaks - should be a penalty of $100 per leaked password - come on, salt and hash them! This would at least put some pressure on that side. Class actions allowed. This would push more towards oauth etc.

Then for targeted attacks, allow non-sms two factor with multiple keys and recovery codes. I'm non SMS two factor on google with recovery codes in a drawer. Have never changed my password and actually have it memorized (and I only use it for google). Same password for 15+ years or so now. Feel totally secure. Google authenticator on phone is pretty good because people really keep track of their phone (more so than yubico keys). I have a yubico on keychain which works 90% (a bit awkward in some cases).

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

#67

Post by xyzzy123 »

tptacek wrote: post #59
xyzzy123 wrote: post #52

Earlier quoted context omitted.

This is a great start. More or less all web sites are technically non-compliant with Australian government security standards (ISM) because TLS has diverged so widely from NIST and those standards dictate NIST approved cryptography. Nobody cares, of course, but it causes pointless conversations and wasted time with auditors.

I'm just pointing it out because I once confidently stated that Curve25519 illustrates everything that is wrong with FIPS, which would, on principle, never accept it, and was thoroughly served with the existence of this document. :) (FIPS is very bad).

I just want to run a "best-practice-ish" TLS setup and have that be compliant :(

Re: FIPS, agree that it is fractally bad [Fully realise I am preaching to choir].

The funny/sad part is that there are financial incentives to be able to say "yes" to customers inquiring about "FIPS compliance" which perpetuates the sham. Service providers (e.g. Amazon, Azure) then necessarily apply "compliance lawyering" (selective interpretation and omission) to give themselves a tick in the box. They can get away with this because their customers are also only pretending to care.

All this serves to create a false impression that "FIPS compliance" might be a real property of nontrivial systems rather than a form of expensive signalling.

I had a longer rant about that here: https://news.ycombinator.com/item?id=15215756

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

#68

Post by josephcsible »

rsj_hn wrote: post #63
tux3 wrote: post #7

Earlier quoted context omitted.

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.

That is a pretty skewed interpretation. FIPS mode does things for you like flag uses of the same private key for encryption and authentication, it prevents the use of weak keys, and prevents use of hobbyist or non-approved algorithms including some sketchy PRNGs. The executable signing also makes monkey-patching harder, so it's more difficult to hook into an implementation and compromise it without detecting this at…

> prevents use of hobbyist or non-approved algorithms including some sketchy PRNGs

It prevents use of good algorithms like ChaCha20/Poly1305, and it allowed the sketchiest PRNG of them all: Dual_EC_DRBG.

> The executable signing also makes monkey-patching harder

Monkey-patching means patching at runtime. This is just as easy to do after the signature has already been verified.

> it will generally run behind and not get the latest algorithms until a few years have passed

It also won't get fixes for vulnerabilities until a few years have passed.

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

#69

Post by gregoriol »

currysausage wrote: post #64
crazypython wrote: post #24

Earlier quoted context omitted.

I assume they are more trusted by older devices than Let's Encrypt. Source?

Relevant for Apple OSs: https://support.apple.com/en-us/HT209143 "Buypass Class 3 Root CA", which appears to be the root certificate they currently use, is present for all listed iOS versions (7+), which seems like a good sign. Let's Encrypt's "ISRG Root X1" is present in iOS 10+. Similar lists for Android would be wonderful but probably impossible to compile due to ecosystem fragmentation. I guess there is no canius…

Thanks, interesting page!

ZeroSSL seems to have their chained "AAA Certificate Services" in the list for iOS 7 (until 2028)

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

#70

Post by mekster »

currysausage wrote: post #15
gregoriol wrote: post #14

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...

How is that a benefit when you automate the renewal process anyway?
Post reply on HN