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

51–60 of 72 posts

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

#51

Post by doublerabbit »

Spivak wrote: post #39
ses1984 wrote: post #6

Earlier quoted context omitted.

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

This is kinda silly. These are problems that, as an industry, we make for ourselves. The fact that you can't make a network connected device that continues to function for decades without a constant maintenance is a problem not a feature.

Sure you can. Make an application that is frozen from future features but can still communicate with the platform at a basic level. Text Messages have been with us for centuries and still compatible with nearly 99% of devices.

Feature updates normally consist of "your device isn't supported and lock the user out without saying Good Bye.

If you create a platform that holds the basic for all versions and don't introduce new features to that; you won't have so much e-waste nor much maintenance upkeep.

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

#52

Post by xyzzy123 »

tptacek wrote: post #38
josephcsible wrote: post #12

Earlier quoted context omitted.

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

https://csrc.nist.gov/publications/detail/fips/186/5/draft

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.

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

#53

Post by ethbr0 »

hannob wrote: post #23
josephcsible wrote: post #21

Earlier quoted context omitted.

Ha, good one. For the average company that breaks SSL, I expect something like this instead: "new corporate policy update: for security reasons, you're no longer allowed to visit HTTPS Web sites that use Let's Encrypt. If the Web site you want to visit still allows HTTP, that continues to be acceptable."

Ain't gonna happen. Let's Encrypt is too big to be ignored. You can't practically use the web like that.

> You can't practically use the web like that.

is looking at a corporate firewall blocking Stack Overflow right now

... "practical" is setting your expectations a bit high.

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

#54

Post by jeroenhd »

slownews45 wrote: post #42
alias_neo wrote: post #35

Earlier quoted context omitted.

Some of it is misguided, some of it is legacy, other parts _do_ make sense to the people involved. Mandatory password changes for example have not been recommended[0] by NCSC in the UK since ~2018. Continuing to do so is either legacy or misguided. As for "MitM" it's usually due to regulatory requirements to protect and inspect at boundaries to and from an organisations network. FIPS and OpenSSL is an interesting sub…

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…

90 days is such a silly time frame. It won't defend against passwords like Spring2018! (11 characters, capital letter, special character, yyet ccompletely predictable) and people will only pick easier passwords when they're forced to pick new ones.

Even Microsoft has stopped recommending regular password changes. I think password changes can certainly be necessary, for example when problems are found during an audit or when there are indications of abuse, but these old rules are making everyone's lives so much harder than they need to be. I hope the IRS will reconsider soon.

Google's method is quite advanced (different tiers of trust for different kinds of services). It makes total sense that you can search the web using an old session, but need to redo the whole 2FA flow if you want to change your password or recovery options. Unfortunately, working such a system out can be quite a challenge because it's hard to get the API segregated into the right trust levels without massively complicating the code flow.

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

#55

Post by benlivengood »

slownews45 wrote: post #42
alias_neo wrote: post #35

Earlier quoted context omitted.

Some of it is misguided, some of it is legacy, other parts _do_ make sense to the people involved. Mandatory password changes for example have not been recommended[0] by NCSC in the UK since ~2018. Continuing to do so is either legacy or misguided. As for "MitM" it's usually due to regulatory requirements to protect and inspect at boundaries to and from an organisations network. FIPS and OpenSSL is an interesting sub…

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 they should have been using multi-factor authentication all along.

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

#56

Post by jeroenhd »

0xbadcafebee wrote: post #29
jeroenhd wrote: post #13

Earlier quoted context omitted.

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 dev…

> It seems quite silly to me to enforce a massive MitM attack while at the same time sticking to the FIPS standards. Well they're two different things. One is an often government-mandated security standard. The other is a business requirement to be able to audit network traffic, which is also often a government-mandated requirement (due to regulations, due diligence, contractual requirements, etc). People making tech…

The reason the government wants FIPS is that it's been verified to be secure according to the national agencies. Enforcing that that security and then putting all if your sensitive traffic in the hands of one key on one box directly contradicts the security requirements FIPS is intended to ensure.

I don't expect the government to have different departments work together around this stuff, but knowing the technical details, the end result is still impractical and stupid. The end result of stupid rules and requirements is that the real world application of technology is stupid, as we have probably all experienced one way or another during our lives.

Just because there's a real business need for something, doesn't stop that from being silly. Correcting the silliness is clearly not a technological challenge, we'll have to wait for politicians and managers to do that, but the end result is still a confusing and contradictory mess.

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

#57

Post by Tepix »

kstrauser wrote: post #19
fnord77 wrote: post #3

Earlier quoted context omitted.

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.

You're underestimating the amount of resources required for chip production.

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

#58

Post by tialaramex »

Spivak wrote: post #40
josephcsible wrote: post #17

Earlier quoted context omitted.

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

Having perfectly functional devices that become obsolete because the world moves around them is also not a good system. We don't have to design our support targets to be a moving window of >= $current_version - 2.

Arguing with time's arrow is fruitless. The world will change, it isn't going to wait around for your OK.

For the most part we aren't talking about needless turnover here. The trust store represents an institutional claim, between now and whenever you stop using this device, all the people who have these private keys will take proper care of them. I actually think that claim is extremely dubious for these Android devices today, it relies on people we meanwhile judged as incompetent to have nevertheless correctly destroyed key materials in their possession when they ceased to do business. I would not be astonished to discover that this already did not happen at least once since the devices ceased to get updates.

For example I imagine all the Symantec roots are included, and likewise StartCom/ WoSign.

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

#59

Post by tptacek »

xyzzy123 wrote: post #52
tptacek wrote: post #38

Earlier quoted context omitted.

https://csrc.nist.gov/publications/detail/fips/186/5/draft

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

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

#60

Post by mrtesthah »

TonyTrapp wrote: post #50
mrtesthah wrote: post #48

Earlier quoted context omitted.

How about macOS for example? After September, Let’s Encrypt will become untrusted on all versions prior to 10.12.

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.
Post reply on HN