Let's Encrypt's Root Certificate is About To Expire, and It Might Break Your Devices (techcrunch.com) 52
One of the largest providers of HTTPS certificates, Let's Encrypt, will stop using an older root certificate next week -- meaning you might need to upgrade your devices to prevent them from breaking. From a report: Let's Encrypt, a free-to-use nonprofit, issues certificates that encrypt the connections between your devices and the wider internet, ensuring that nobody can intercept and steal your data in transit. Millions of websites alone rely on Let's Encrypt.
But, as warned by security researcher Scott Helme, the root certificate that Let's Encrypt currently uses -- the IdentTrust DST Root CA X3 -- will expire on September 30. After this, computers, devices and web clients -- such as browsers -- will no longer trust certificates that have been issued by this certificate authority. For the overwhelming majority of website users, there is nothing to worry about and September 30 will be business as usual. Older devices, however, could run into some trouble, much like they did when the AddTrust External CA Root expired back in May. Stripe, Red Hat and Roku all suffered outages as a result.
But, as warned by security researcher Scott Helme, the root certificate that Let's Encrypt currently uses -- the IdentTrust DST Root CA X3 -- will expire on September 30. After this, computers, devices and web clients -- such as browsers -- will no longer trust certificates that have been issued by this certificate authority. For the overwhelming majority of website users, there is nothing to worry about and September 30 will be business as usual. Older devices, however, could run into some trouble, much like they did when the AddTrust External CA Root expired back in May. Stripe, Red Hat and Roku all suffered outages as a result.
TLS is a timebomb (Score:5, Interesting)
Some older devices can be easily updated, but far too many can't or can't without involving the vendor.
Just one more thing to consider when thinking about 'right to repair'...
Re:TLS is a timebomb (Score:5, Funny)
Also another downside to the idea of "encrypt everything".
Re: (Score:1)
Also another downside to the idea of "encrypt everything".
No, the problem is not encrypting everything. That's actually a good idea. The problem is encrypting with a certificate that "expires". That's just fucking retarded.
Re: (Score:2)
At least for expiration the theory that an abandoned or unknown compromise is at least eventually stop being a potential problem.
Now the 'not valid until' bullshit...
Re: (Score:2)
The problem is the highly centralized certificate "authority". Very convenient kill switch, don't you think? Pretty sure this is the intent behind the whole thing.
Re: (Score:2)
The problem is the highly centralized certificate "authority". Very convenient kill switch, don't you think? Pretty sure this is the intent behind the whole thing.
No one is forcing people to use a "centralized" authority. Setting up your own Certificate Signing Authority is surprisingly easy using something like OpenSSL [openssl.org]. The widely-recognized CSAs are more convenient to use, however, since their certificates are already trusted by software like Chome, Firefox, Edge, etc.
Re: (Score:2)
Aren't CA's are just a work-around to the identity verification problem? Encryption and secure key exchange seem to be solved, at least for our level of technology. 'Web of trust" as an alternative seems impractical. But what I wonder if we need them?
Now, I'm not a cryptography expert by any means, so keep that in mind. Why isn't just Diffie–Hellman and AES good enough for most normal use, and why things requiring more security can't just use some out-of-band key. I'm imagining something like a Q
Re:TLS is a timebomb (Score:5, Informative)
Certificates do not provide encryption. What they do is provide a method of saying that the server you just connected to has a private key which someone you supposedly trust (the CA) says belongs to that server. If you don't verify that connection, it doesn't matter how strong encryption you use, because whatever you connected to can decrypt the traffic.
Yes, you could use something like a QR code to enter that information into your device. But how do you know the QR code itself is authentic? Even if you do use something like a QR code, that would probably at most be providing the 'root' certificate of your bank's own CA. Your bank isn't going to be giving you QR codes for every one of the dozens or hundreds of servers you might connect to when you go to 'yourbank.com'. All you've done is replaced a few trusted CAs with potentially very many CAs, depending on how many sites you connect to. And, to top it off, you get to manage all that instead of your browser provider.
Somewhere along the line you have to trust something. Sure, you may trust a QR code you get from your bank, but what about all the other places you want to securely connect to? How do you manage all that stuff (on every device you have)? How do you make sure you (and everyone else) delete something that is no longer valid (maybe your banks private key was compromised somehow)?
CAs are a tradeoff. No, they don't provide perfect verification. But they are easy to use, and the average person doesn't have to do anything to benefit from the verification they provide.
Re: (Score:2)
Okay, it's clear that you didn't understand my question. I'm not sure you even read it. I'm almost insulted by your reply, as I can't see how you could have composed what you did in response to what I've written.
Certificates do not provide encryption.
I never said they did. I was very clear about the role that certificates play. It's the very first thing I wrote.
But how do you know the QR code itself is authentic?
Because I got it from my bank? As you said: "Somewhere along the line you have to trust something". This seems a lot more trustworthy than anything done online. I'll also note that
Re: (Score:2)
MITM attacks are certainly not difficult to do. Did you ever use a hotel (or other public) wifi, and the first page you try to go to comes up with a big 'connection not secure'? That is because they are returning their own T&C web page instead of the site you wanted to go to, and the certificate does not match the expected server. Instead of returning their own page, they could just capture everything in your request, then forward the request to the real site. The certificates prevent this.
As for you
Re: (Score:2)
Expiring roots is just a necessary ill. If you explicitly trust every organization of whom you deal directly, you don't need to trust any roots, but the downside to that is manual configuration and all entities need to understand how certificates work.
Failing that, the root CA needs to remain secure against a large attack surface for the entire duration. Even strong crypto methods and secure personnel at those entities can only ensure this for a limited time window, after which the best assumption is to c
Re: (Score:2)
I imagine one of way of explaining it is blind trust vs renewed trust. Today you trust your politician, but who knows if they have been compromised tomorrow, so you need to update your trust relationship instead of just accepting blindly. At the same time there is a notion that the common authority your browser trusts is also legit, so there is a weakness, but I am not sure trust is ever 100% even in human relationships.
The above scenario has happened when a number of CAs went bad.
Re: (Score:2)
The problem here is crappy devices made by crappy vendors with no right to repair, and no continued update support for their junk. Encrypt everything is good, and expiring certificates is a necessity.
Re: (Score:2)
Re: (Score:2)
Also another downside to the idea of "encrypt everything".
You got a moderation of "funny", but this is actually a very real problem. Encryption increases system complexity and increases maintenance needs. In many cases, it may be better to _not_ encrypt.
Re: (Score:1)
We need these "certificate authorities" to turn off the internet with a single button when given the order
Re: (Score:2)
Good point. Without some right to repair software... the only solution I see is a slightly scary button on the old devices that say "OK, I'm going to trust this cert/whatever anyway, even though xyz." That at least allows you to save a buck and you should know you are taking things into your own hands. Maybe have that feature take a few steps that deters the average Joe who wouldn't know what he was doing anyhow.
Embedded should ignore the expiration date (Score:2)
This is one argument as to why embedded systems should just ignore the cert expiration date.
The date is there so CAs can sell more certs*. If something's secure it should not be secure for a given amount of time. And if it is, well, the client should be able to determine how long is too long (which is why you shouldn't validate expiration dates in embedded).
* Not really, but mostly.
Re: (Score:2)
Android, which is the big problem, does ignore the expiry date. It still didn't stop the product I work on breaking on older Androids a few weeks ago when the auto-renewal of the LetsEncrypt certificate was handed a cert signed by the new root without the cross-sign from the old root.
Re: (Score:2)
Nothing is secure forever. Last decade's "unbreakable" is next decades "10 minutes on AWS". So the effect of your statement is "nothing is secure", which while technically correct (the best kind of correct) makes it really hard to get anything done.
So yeah, we really do need "this is considered secure for X time and after that probably not so much".
Re: (Score:2)
Just one more thing to consider when thinking about 'right to repair'...
Or I don't know... how about holding the vendors accountable when they do stupid stuff? Like not maintaining a proper software update schedule that only contributes the e-waste problem of the world. Yes, I'm looking at you Samsung, you're the worst of the bunch.
Re: (Score:2)
No one has told me why I should trust Any Cert? (Score:3)
Back in the olden days, getting a Cert was a few hundred bucks, but it also came with a lot of work where they actually verified that you were who you said you were.
They have gotten lax over the times, so a Cert from an authority can be just as much as a scam, as a Self made Cert. As well a Self made Cert doesn't make the encryption any less effective.
It is somewhat useful with a man in the middle type of hack, however that makes a very detailed type of hack, wither even a cert may fail if the order of operations don't go exactly as planned.
Re: (Score:3)
The purpose of the cert is to validate that the server you connected to is the server you intended to connect to. Is it perfect? No, but what are the alternatives?
If you do nothing, then MITM attacks become much easier and you might as well not bother with encryption.
If you use a self-signed cert, then you must have some trusted way of distributing the public key. In addition, you must have every one of your users install that public key (cert) in whatever they are using. That becomes a user nightmare.
Re: (Score:3)
Speaking for myself, I wish that DNSSEC was offered as an alternative. I think it could be a simple as placing the self-signed certificate hash in a TXT record. Such a system wouldn't even need to replace the current CA approach, but it would provide a low-cost alternative for those who wanted to self sign.
Re: (Score:2)
Aren't you then just replacing one centralized trust anchor (the TLS CA), with another (the signing key used by the DNSSEC registrar)?
Re: (Score:2)
Demonstrating control over the domain is sufficient to get you a legitimate DV certificate from most CAs; moreover, any CA can issue a certificate for any domain whether you deal with them or not. Certificate Transparency helps, but only if you monitor it vigilantly. By using DNSSEC (DANE) instead you're replacing many trust anchors—all the trusted CAs, plus the DNS hierarchy they rely on—with just two: the DNS root and the registrar for your TLD.
Re: (Score:2)
What is the advantage of that over something like Lets Encrypt (which is free)?
Re:No one has told me why I should trust Any Cert? (Score:4, Insightful)
What is the advantage of that over something like Lets Encrypt (which is free)?
Certificates from Let's Encrypt are only valid for three months. Not a big deal if you're using them in an application where renewals can be automated, but I imagine there are applications where replacing your certificate every three months might be a hassle.
Re: (Score:3)
What you are asking for has already been designed by the IETF: DNSSEC DANE TLSA. It is the solution for all root certificate store woes.
All major browser vendors have had open tickets to implement TLSA for 9+ years. Absolutely no work has been done to implement the protocol. Firefox and Chromium devs, however, have found plenty of time to change the look and feel of their browsers several times over much to the chagrin of every user. You know, instead of implementing security measures like TLSA that se
Re: (Score:3)
The purpose of the cert is to validate that the server you connected to is the server you intended to connect to. Is it perfect? No, but what are the alternatives?
People are not even trying. There are a number of reasonable alternatives.
One alternative is to push this out to the domain registrar to issue certificates as a normal part of domain ownership.
If you don't like that idea a simple token exchanged with the domain holders registrar to establish proof of identity would also be relatively simple to implement.
Personally I think what should eventually happen once DNS transport issues are resolved is for DVs to just go away/out of business and everyone switch to D
Re: (Score:2)
If MITM attacks are so simple, why hasn't every bank web site been MTIMed?
Re: (Score:2)
If MITM attacks are so simple, why hasn't every bank web site been MTIMed?
What limits who can attack is who has access to a sites traffic.
Re: (Score:2)
How does access to a site's traffic allow you to get a certificate and do an MITM attack?
Re:No one has told me why I should trust Any Cert? (Score:5, Informative)
How does access to a site's traffic allow you to get a certificate and do an MITM attack?
DV CAs use automated testing to establish you control a site before granting access to a certificate for that site. Tests are based on queries via insecure protocols typically DNS or HTTP.
All you need to do is purchase a certificate for your victims site and manipulate incoming validation requests from the CA to pass their automated tests. In exchange they hand you a valid certificate for the site matched to a private key you control.
From this point forward you are able to manipulate incoming requests from the sites users to handshake using your site certificate instead of the sites certificate. In the victims browsers they see a perfectly valid certificate for the site yet it belongs to the attacker not the legitimate owner of the site.
Re: (Score:2)
SSL certificates are only issued to people who can prove they own the domain nam
Re:No one has told me why I should trust Any Cert? (Score:4, Interesting)
It never involved a lot of work and the verification was always cursory at best. They charged hundreds because they could. Way back when it was all being rolled out, I asked a representative how they know the person requesting a certificate wasn't lying and the best answer he could come up with was because they sign a legal agreement saying they aren't.
All it ever took was something with the official letterhead. They always ignored that a high school student could easily figure out how to fake that using commonly available tools. It was always about the rent seeking opportunity.
Now that that's been pushed as far as it can be, suddenly Apple and Google are in a race to see how frequently they can get everyone to jump through the flaming hoop.
Re: (Score:2)
Back in the olden days, getting a Cert was a few hundred bucks, but it also came with a lot of work where they actually verified that you were who you said you were.
They have gotten lax over the times
Congrats on not understanding what a cert does. Hint: DV certificates which are the ones being issued don't have anything to do with you being who you say you are. They are exclusively about the server being who it says it is, and that is verified electronically via a simple lookup. Nothing lax about it.
If you buy an EV certificate you will very much still be asked to show ID.
Re: (Score:2)
Congrats on not understanding what a cert does. Hint: DV certificates which are the ones being issued don't have anything to do with you being who you say you are. They are exclusively about the server being who it says it is, and that is verified electronically via a simple lookup. Nothing lax about it.
If you buy an EV certificate you will very much still be asked to show ID.
jellomizer is correct. Originally the only way to get any secure certificate was to go thru hoops comparable to EV certificates today. There was no lights out automated $10/year option. There was no such thing as DV v. EV.
Re: (Score:2)
Being correct doesn't mean what he said was relevant. We solved the problem of certification for encryption in a technical way, that doesn't mean it's not trustworthy. Heck I'm inclined to argue it's more trustworthy now than it was in the past.
Re: (Score:2)
The distinction being somewhat pointless, as all special treatment of EV certificates has gone away.
The timeline was a push for everything to be https, EV certs held up as 'here's us still preserving a higher standard of validation' to assuage the concerns of people concerned that the point of certs would be diminished by aggressive push of easy certs everywhere. Then once Lets Encrypt was pretty ingrained into the reality of the internet, the browsers promptly dropped any special treament of EV.
It was a bi
Re: (Score:2)
Not at all. EV certs have always been rife with simple fraud possibilities whereas in reality what we were using these systems for was securing communication between two machines.
Now that you have to use a technical process to prove you are the controller of a domain to get a DV certificate I'll argue you are far more secure against a MITM than in the past where you relied on some dude checking some documents from some other dude to see if they are who they say they are.
The problem is not that DV is weak, i
Re: (Score:2)
. Hint: DV certificates which are the ones being issued don't have anything to do with you being who you say you are. They are exclusively about the server being who it says it is,
And, not even that: if the attacker controls the route to the server, in a spot close enough to the server (such as rogue or hacked datacenter operator), then he is in a position not to only mount a Mitm attack, but also to get a valid DV certificate.
So DV certificates are indeed weaker than OV certificates with a manual verification. However, they still do protect against attackers who control the route from client to server on a spot that's close to the client (i.e. rogue Wifi access point)
The CA hierarchy is a faulty design (Score:2)
Re: (Score:1)
The CA hierarchy is a faulty design
No, it's "faulty" by design. Centralization is key
just in time... (Score:2)