Slashdot Mirror
Let's Encrypt Hits New Milestone: Over 100,000,000 Certificates Issued (letsencrypt.org)
Josh Aas, the executive director of Internet Security Research Group (ISRG) writing for Let's Encrypt: Let's Encrypt, a free, automated, and open certificate authority has reached a milestone: we've now issued more than 100,000,000 certificates. This number reflects at least a few things: First, it illustrates the strong demand for our services. We'd like to thank all of the sysadmins, web developers, and everyone else managing servers for prioritizing protecting your visitors with HTTPS. Second, it illustrates our ability to scale. I'm incredibly proud of the work our engineering teams have done to make this volume of issuance possible. I'm also very grateful to our operational partners, including IdenTrust, Akamai, and Sumo Logic. Third, it illustrates the power of automated certificate management. If getting and managing certificates from Let's Encrypt always required manual steps there is simply no way we'd be able to serve as many sites as we do. The total number of certificates we've issued is an interesting number, but it doesn't reflect much about tangible progress towards our primary goal: a 100% HTTPS Web.
I'm not sure that one of these certs is any better than a self-signed cert...
If you want news from today, you have to come back tomorrow.
The Let's Encrypt certs that I have for my websites automatically expire and renew every 30 days. That's 360+ per year.
That's the scam - the pretense of "identification." All certs do is encrypt the stream. The CA "knows" you only as well as it's able to ascertain your actual identity, which for 99.9% of certs, is near zero. That's quite aside from any breaches in security that result in the cert getting into the wild and DNS malfuckery coming into play.
The reason that lets-encrypt has succeeded is because it avoids the money-generating browser manufacturer / CA collusion scam, and there isn't anything better yet than lets-encrypt's approach of constantly renewing the certificate (unless you're willing to have the browser scare away the vast majority of your visitors, which, again, is the scam.)
If someone pops up with a quality browser that reasonably treats self-signed certificates, the entire fraudulent business model of the CA's will collapse. It's long overdue. But there are huge monetary interests involved, so don't hold your breath.
TL;DR: Traditional CAs are scammers. Their claim of providing "identity" is no more than smoke and mirrors. lets-encrypt provides the actual value - encryption - without the baseless-identity-for-money scam. That's why lets-encrypt is a success.
This thing is the best thing since sliced bread. I use it on all my servers, it saves me money and head aches.
Won't stop Punycode Phishing.
What you're missing is that there are some extremely technologically-stupid people in tech, and the rest of the world has to deal with their bullshit.
These extremely stupid people think that self-signed certs are somehow bad, or even inferior to plaintext! And the disaster the world has ended up facing, is that these fucking retards ended up having a say in how most people's web browsers user interface works.
The result is that web browsers often show warning boxes when faced with a self-signed cert, rather than the UI simply lacking an indicator that you have a certain minimum confidence that that you know with whom you're connected. This is a serious defect in most web browsers, possibly even the one that you personally use. I bet you have this problem.
And by all signs, none of the major web browser teams ever intend to repair the defects.
Using a shitty CA, instead of self-signing, works around the user interface flaw. Now the broken web browser correctly abstains from user-confusing "add security exception" nonsense, and things Just Work.
Of course, the downside is that the user might incorrectly infer that the other party is authenticated, but we already had that problem with other CAs too. HTTPS' reliance on single-signed x.509 and faceless CAs means that it'll never be particularly good for security purposes, or at least not on the Internet (though it is good enough for your company's intranet services).
What is the respomse from commercial xert businesses about Let's Encrypt?
If you want news from today, you have to come back tomorrow.
Self-signed certs are worse than plaintext from an HCI perspective, because they provide the appearance of security, while providing very little actual security.
In contrast, a cert signed by Let's Encrypt at least tells you that the example.com that you're talking to is the same one that the Let's Encrypt server was talking to. It's a lot easier to compromise a random WiFi AP than it is to compromise the connection in the datacentres that Let's Encrypt uses and a random WiFi AP.
I am TheRaven on Soylent News
That's upwards of $2 billion in "lost revenue" for the certificate cartels (using MAFIAA math)
The number mainly reflects the short expiry time on these certificates.
"This number reflects at least a few things: First, it illustrates the strong demand for our services."
Only because you, Mozilla - the PRIMARY funding source for Let's Encrypt - refuse to implement DANE TLSA yourselves.
https://bugzilla.mozilla.org/show_bug.cgi?id=672600
"Second, it illustrates our ability to scale."
DNS scales just fine. We don't need Let's Encrypt. What we need is DANE TLSA. Stop blabbing and dragging your feet on the issue and go implement it. This is a global security issue far greater than whatever the latest ransomware strain is. Also, screw you for waiting 6+ years to implement the feature to correct a 15+ year oversight that Netscape, which ultimately became Firefox, created.
"Third, it illustrates the power of automated certificate management."
Great. Now go implement DANE TLSA. It also illustrates the power of what free SSL certificates created by an organization that may be required to secretly hand over its private signing keys to the U.S. government via a FISA court order is capable of. That's 100 million compromised websites. Let's Encrypt is a U.S. based organization and FISA, NSA, CIA as well as all of the usual foreign players are all interested parties in your signing keys. I may deploy Let's Encrypt but I don't trust a single byte of data encrypted with Let's Encrypt signed certificates as being truly protected. Let's not fool ourselves here: Your service is convenient for getting the lock icon and browsers and other software to shut up about stuff but it's not remotely secure.
"The total number of certificates we've issued is an interesting number, but it doesn't reflect much about tangible progress towards our primary goal: a 100% HTTPS Web."
Then go implement DANE TLSA and eliminate the need for public CAs once and for all. DANE TLSA allows an individual or an organization to create and manage their own root CA without requiring it to be installed in the browser trust root store and yet compliant software will trust it. We can finally empty out the entire trust store as soon as DANE TLSA is widely deployed. The ONLY reason you AREN'T implementing it is because a bunch of other organizations have graced your head-filled arse with money to get their CA roots into the web browser trust stores of all major browsers.
Can you explain specifically what makes this better than self-signed certs?
Self signed certs don't certify much (beyond the cryptographic validity of the key pair).
That means, on your first visit, that it's YOUR burden to check it that certification really belong to the domain, before trusting it and adding it.
(It could be a Man-in-the-Middle with their own self-signed certificate).
On the other hand non-EV certificates and Let's encrypt, all require some proof that the certificate requestor has a control of the server
(depending on the entity issuing the certification: requestor can answer "webmaster@[website.com]" e-mails (e.g.: CaCert), or that the requestor can publish and sign information on "https://[website.com]/nonce" (Let's Encrypt), etc.)
It's always steps that :
- can easily be automated (e.g.: no need to review official legal documents by staff. Unlike EV certificates)
- are steps that can only be done if the requestor has actually control of the domain.
So when you go to [website.com], if the certificate is a non-EV certificate or by Let's Encrypt, you have the guaranty that this certificated was delivered to the people genuinely controlling [website.com].
It's very unlikely that an attacker is ini the middle.
Note that this type of certificate only confirms the address of the website.
It provides no other information about the owner.
i.e.: a Let's Encrypt certificate gives you guaranty that "www.paipall.com" is indeed this website with no middle man attacker.
(you get a padlock in browser URL bars. Like Slashdot.org).
it's doesn't say anything if this website is actually owned by PayPal Inc or someone else. That would require an EV certificate (with a legal team reviewing the official papers to confirm or not)
(taht gives a padlock and a company name in browser URL bars, like paypal.com)
What prevents an attacker with access to a victims wires from using LE to obtain fraudulent certificates?
The attacker would *ALSO* need to have access to the server they are trying to impersonate in order to successfully pass the validation.
(And by that point, if the attacker actually controls that server, there's no need to fuss around with man-in-the-middle attack).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
because they expire every three months.
Are you sure that's not another user interface defect? You sure just described it as a user interface defect.
The attacker would *ALSO* need to have access to the server they are trying to impersonate in order to successfully pass the validation.
(And by that point, if the attacker actually controls that server, there's no need to fuss around with man-in-the-middle attack).
An attacker could use LE to setup a MITM attack, if they can hack the website.
As I've explained in the quote you're replying to, if the attacker has control of the website, they can do pretty much everything they want.
At that point, getting a LE certificate is spending needless time on useless stuff that won't bring you much access beyond what you do.
1) Take control over the website.
At that point, the attacker has access to everything they could dream of. :
You can straigth jump to
4) Phish a user into going to their MITM site, which has a LE signed certificate, that your browser trusts.
Why MITM site ? The attacker has access to the real deal.
They could steal data straight from the actual site if they want.
Why LE signed certificate ? (Or for that matter CaCerts, Starcom or any non-EV option at one of the big name certificate authority). The attacker has access to the actual original private key on the site.
If anything, a changed certificate or even a changed authority might look conspicuous (and some power users have tools to detect exactly that).
Why setup a separate LE certificate, when they can use the actual key and rely on whatever expensive signing the site went for ? (and then, for all intent and purpose, the interaction with the pish looks cryptographically exactly the same as if coming from the genuine site. There's no cryptographical way to distinguish them).
At the point where an attacker controls the website, you're pretty much hosed and the fact that they could get a certificate from Let's Encrypt (or from CaCerts.org) (or pay a non-EV certificate from any of the expensive trusted certificate providers) is a minor details compared to the potential of damage they now have access to.
There isn't much difference between Let's Encrypt, CaCerts.org, or a non-EV certificate that you can get from any of the classical providers.
The only thing that Let's Encrypt has brought to the table is their "ACME" protocol, making things also easier to automate on the website owner's side of the business and providing a reasonable set of defaults. (With LE, even Joe Six Pack can have https on their own blog).
The big distinction is between EV and non-EV certficates.
non-EV certs (including from classical sources, but also including Let's Encrypt and CaCerts) : only guarantee (through automated means) that the website is indeed the URL it claims to be - (padlock in URL bar)
EV certs : actual human staff is paid to check extensive legal/official paper work to guarantee that the website belongs to a legal entity (a registered company) - (company name in URL bar).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]