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.
This thing is the best thing since sliced bread. I use it on all my servers, it saves me money and head aches.
What is the respomse from commercial xert businesses about Let's Encrypt?
If you want news from today, you have to come back tomorrow.
1. There is no pretense of identification.
2. Learn the basics about certificates and what they ACTUALLY mean rather than what meaning you give them for whatever reason.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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
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.
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 ]