Can anyone list any negatives of Let's Encrypt? I've been using it since the start and just can't find any practical downsides.
My biggest peeve with the whole "HTTPS Everywhere" push is not the general notion of using encryption, but that the encryption is annoyingly coupled with the CA system, which is terrible for many reasons.
CAs seem like a system that really doesn't work today, we've seen multiple times that many of these CAs aren't worth delegating trust to to begin with, and it causes an unnecessary cost and burden upon just... encrypting traffic.
Are you sure that all "old school" CAs wouldn't issue a cert for that?
They were never supposed to fight phishing. Domain Validation certificates literally validate… domains, and nothing more.
It would make more sense to prevent googIe.com from existing at the .com registry level, before any TLS is involved.
So you’re sitting in a cafe, and you go to Facebook.com. Lo and behold, someone’s installed a MITM proxy on the router, that presents its own encryption key instead of Facebook’s, and your browser has no way to tell this because the CA system isn’t a thing. They now have your password, can steal your session to spam your friends, whatever else. How do you prevent that?
Automated domain validated certificates are meant to ensure that when you go to Facebook.com, you’re talking to Facebook.com and not a MITMing router on the way there. They’re not meant to protect against phishing - they’re meant to protect against the very real cases I’ve seen where my mobile ISP adds random JavaScript into the web pages I view, and sells information about me based on my use of the web.
Given the exploitability, laziness, general failure to follow best practices, not to mention misaligned incentives that we're seeing from major CA vendors, having centralized CAs seems like an ever-worsening solution.
In other words, if someone claiming to be Facebook has told a significant number of people all over the world that Facebook's cert fingerprint is ABCD124, and that fingerprint matches what they're getting presented, it's probably legitimate. We can add additional points for the cert signer being the same one as the previous cert, lack of listing in a CRL, cert transparency logs, etc.
There's no reason this system couldn't bolt on top of the existing CA infrastructure to avoid a bootstrapping problem either.
It adds a probability value into the mix, in other words. That value has always existed, but now we expose it to the user in some way and stop pretending that it does not.
I can use HPKP to pin the cert I get from Lets Encrypt; a cert issued for my domain some other way won’t be trusted due to the hash of its public key being different from the one I pinned.
From https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key...:
The Public Key Pinning Extension for HTML5 (HPKP) is a security feature that tells a web client to associate a specific cryptographic public key with a certain web server to decrease the risk of MITM attacks with forged certificates.
HPKP makes administration more complicated but if your threat model includes state-level actors, it prevents them from getting a CA to issue a valid certificate for your domain.
Certificate Authority Authorization (CAA) has been mandatory for CAs since September 2017; it uses DNS to specify which CAs are allowed to issue certificates for your domain: https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-c....
single point of failure as in, getting hacked and misiussing certificates?
It's a concern whenever a large portion of decentralized infrastructure has a single centralized dependency. Even if that dependency is awesome and doing great work right now.
Ideally, there would be several free CAs that all used the ACME protocol. But somebody's got to pay for that and somebody's got to go through the effort of setting it up when Let's Encrypt already works really well.
It would be nice if they simply offered two choices:
1. I love automation! Give me a 90 day certificate.
2. I understand the security trade-offs. Give me a 3 year certificate.
For future reference - the BRs have a section with a timeline, it's great for finding upcoming or recent changes significant enough that the CAs needed a deadline.
They also pretend, that compromising 3-months certificate is "ok" (or at least less harmful, than compromising a year-long certificate), when in practice there is no reason to assume so, — 3 months is more than enough for any real-life eavesdropper.
Firstly, CA/B explicitly can't talk about pricing or product offerings, because a group of businesses that collaborate on setting prices or product offerings is called a Cartel and is illegal (the example you're probably thinking of, OPEC, exists because its members are sovereign entities, and thus enjoy total immunity from the law). When they meet in person the CA/B members always begin by reading out the rules that lay out what mustn't be discussed for this reason.
Secondly, the idea is not at all that compromising 3-month certs is "ok". Instead Ryan's focus is on the pace of change. During 2016 CAs agreed to use the Ten Blessed Methods for validation, in 2017 that agreement became a concrete rule (thanks to Mozilla) but a 39 month certificate issued under the prior validation status quo would still be trusted until mid-2020.
Historically what has happened is that there's a grace period, and then CAs are supposed to go back and revoke any certificates still outstanding that break the new rules. But this is error-prone, back in early 2017 you can see the list of violations I found while checking that certificates for now prohibited "internal" names were revoked as required, each CA had excuses for why they'd missed some, but the overall lesson is that things will be mised. So Ryan doesn't want to rely on grace periods, he wants a shorter window of validity for the certificates.
MD5 and SHA-1 is the go-to example for this stuff. We expect already that SHA-2 (e.g. SHA-256 used currently in certificates) will fall the same way as the others, because it's the same construction, so we're going to be doing this again in perhaps 5-10 years. But with 39 month certificates the _minimum_ time from changing the rules to getting rid of the problem is 39 months, if it takes a few months to agree what to do, the total may be closer to 4 years. That's a very long time in cryptographic research, too long to predict what's coming. 90 days would be much better from this perspective.