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.
It's trusted by the browser by default, so it has that going for it.
Also, unlike self-signed certs it demonstrates that the person requesting the cert has control over the hostname(s), which is pretty much all I ever had to do when I paid for a non-EV certificate.
If I have been able to see further than others, it is because I bought a pair of binoculars.
Im not that poster but I do have to look after a lot of servers with sites that have letsencryprt certs.
Basically it requires the same level of domain validation as any standard, non EV cert (including revocations) and provides the same level of protection for on the wire data interception with the disadvantage that certs are only issues for 90 days instead of 1+ years.
Look here for a overview of the the process, its pretty simple and the same as any other non EV cert:
https://letsencrypt.org/how-it-works/
This isn't about the basics of PKI it's the basics of establishing TRUST that's the heart of my question regarding LE.
The basis of any secure system is TRUST not alphabet soups of cryptographic jargon. It's asking the basic question "WHY SHOULD I TRUST YOU?" and receiving a reasonable, verifiable response.
Trust whom, the site owner? LE? Their CA? If you don't trust root CA, then you are SOL. Better unplug your computer. Otherwise, there's your trust chain: root CA vets LE to a level sufficient to grant them an issuing certificate, LE vets the site owner to a level sufficient to grant them a hostname certificate.
How does LE vet ownership to even assign certificates in the first place?
Ownership of what, the hostname? The client requesting the certificate has to satisfy a challenge, for example placing a file with specific contents at a specific location controlled by the hostname, or populating a specific DNS record with a specific value for that hostname's zone. If the client is able to satisfy those challenges, then it already has complete control over the hostname and the content it serves.
What makes this process secure and trustworthy? If there is no good answer to that question all the cryptography in the world means nothing.
If you aren't willing to engage in a discussion about public keys and cryptographic signatures, there's no way to answer this question for you. The cryptography is how the process is secured, and the public key nature (combined with satisfying the challenge above) is how the CA establishes trust.
The point being you connect to http, and no worries, it's all cool. It's warm and fuzzy and not at all something to fret about.
You connect to https with self-signed cert, *IT'S THE END OF THE WORLD*, you are horribly insecure, it's dangerous, you shouldn't even *try* to talk to the server, if you really want to you should click through 2 or 3 dialogs, and also you should be forced to do that every time you reconnect to the same server, without even a hint of whether the certificate changed from last time.
It's just such a strange disconnect. I have seen web server operators opt to prefer http rather than https so as not to scare off users, even if they may be handling potentially sensitive information.
Self-signed certs should be treated more like ssh keys in general.
XML is like violence. If it doesn't solve the problem, use more.
Also, unlike self-signed certs it demonstrates that the person requesting the cert has control over the hostname(s), which is pretty much all I ever had to do when I paid for a non-EV certificate.
How does it demonstrate that?
Because one must create a file under a name specified by LE, with contents specified by LE.
Only one with control over the webhost has access to create files on the webhost.
Can you explain specifically what makes this better than self-signed certs?
Anyone can create and sign a self-signed certificate with any domain(s) in it they wish.
You can not easily verify the website owner is the creator of the private key, and in fact the only one way to do so is to compare the certificate signature/hash you see with the website owner, which requires another form of secure out-of-band communications.
With LetsEncrypt, you personally for example can not issue a certificate for my domain.
I personally can not issue a certificate for your domain.
Additionally with self signed certificates, you would need to have end-users install your self signed public key in their browsers manually, and to actually be secure it would have to actually be the one you generated.
As an attacker I can provide my own public key to your users to trust, with your domain in it, and there is little chance they wouldn't know it was my key instead of yours.
Certificate Authorities have their public keys in the browser already.
What is the basis of trust used to establish ownership?
Access to a web servers files or DNS zone for the domain in question is required.
This is the exact same identical process any other CA in the world uses for class-1 certificates.
In other words, if you know how any CA handles class-1 certs, you know how LE handles them. It is identical.
What prevents an attacker with access to a victims wires from using LE to obtain fraudulent certificates?
What prevents a person with control over the domain from requesting a certificate for that domain?
The exact same thing that prevents an attacker from getting a certificate from any CA issued for that domain - nothing.
If I was an attacker in that position to have control over a victims web host or DNS, I could get a certificate issued from Lets Encrypt, or GoDaddy, or ICANN, or any of the many hundreds of certificate authorities out there.