SoylentNews is people
SoylentNews
Professor J. Alex Halderman, the noted election security researcher, along with his co-authors, have published a summary of Let's Encrypt, its components, and what it does. (Warning for PDF.) The service Let's Encrypt is a free, automated, open certificate authority (CA) to provide TLS certificates. These are usually for web sites, enabling them to provide HTTPS connections.
Since its launch in late 2015, Let's Encrypt has grown to become the world's largest HTTPS CA, accounting for more currently valid certificates than all other browser-trusted CAs combined. By January 2019, it had issued over 538 million certificates for 223 million domain names. We describe how we built Let's Encrypt, including the architecture of the CA software system (Boulder) and the structure of the organization that operates it (ISRG), and we discuss lessons learned from the experience. We also describe the design of ACME, the IETF-standard protocol we created to automate CA–server interactions and certificate issuance, and survey the diverse ecosystem of ACME clients, including Certbot, a software agent we created to automate HTTPS deployment. Finally, we measure Let's Encrypt's impact on the Web and the CA ecosystem. We hope that the success of Let's Encrypt can provide a model for further enhancements to the Web PKI and for future Internet security infrastructure.
[...] Prior to our work, a major barrier to wider HTTPS adoption was that deploying it was complicated, expensive, and error-prone for server operators. Let's Encrypt overcomes these through a strategy of automation: identity validation, certificate issuance, and server configuration are fully robotic, which also results in low marginal costs and enables the CA to provide certificates at no charge. We designed Let's Encrypt to scale to the size of the entire Web. In just over three years of operation, it is well on its way: it has issued over 538 million certificates and accounts for more valid browser-trusted certificates than all other CAs combined. We hope that in the near future, clients will start using HTTPS as the default Web transport. Eventually, we may marvel that there was ever a time when Web traffic traveled over the Internet as plaintext.
Let's Encrypt: An Automated Certificate Authority to Encrypt the Entire Web, Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, Pages 2473-2487 (DOI: 10.1145/3319535.3363192
Earlier on SN:
Let's Encrypt to Transition to ISRG Root (2019)
Three Years Later, Let's Encrypt Has Issued Over 380 Million HTTPS Certificates (2018)
Let's Encrypt is Now Officially Trusted by All Major Root Programs (2018)
Let's Encrypt Takes Free "Wildcard" Certificates Live (2018)
Free Certs Come With a Cost (2017)
Let's Encrypt Issues 100 Millionth Certificate (2017)
Let's Encrypt Won its Comodo Trademark Battle - but Now Fan Tools Must Rename (2016)
Let's Encrypt Gets Automation (2015)
(Score: 3, Interesting) by ikanreed on Tuesday November 19 2019, @03:22PM (8 children)
It's not without reason to believe a hacker with temporary non-elevated control of a server couldn't successfully follow the automated process as part of an intrusion. Then you could effectively MITM that server for years, and no one would know about it.
(Score: 5, Interesting) by isostatic on Tuesday November 19 2019, @03:31PM (3 children)
First you would need to have control to serve pages on port 80. Lets assume you get that, LE Certificates are only valid for 90 days, so MITMing that server for "years" wouldn't be possible. You could do exactly the same with a certificate from elsewhere, except those certificates do last years (2 years)
You could do the same thing if you can hijack BGP too
Certificate transparency will show up so your legitimate server admin, and your DNS admin can set a CAA record to prevent it from happening.
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @04:34PM
Not if you hijack BGP and get cert from same CA, which would be Let's Encrypt.. Then you can MITM despite CAA records. You would need to have TLS-DANE records instead which make CAs obsolete anyway.
Everyone is too lazy to use that so, yeah, MITM BGP hijacks can get automated certs issued. Yay for CA model!
Maybe you can protect against this with DNSSEC signing of records to get your CA, but Let's Encrypt doesn't allow delegation to other signed zones making this definitely not automated and cumbersome.
(Score: 2) by Pino P on Tuesday November 19 2019, @10:17PM (1 child)
You don't even need to hijack BGP. If you have control of BANKOFARNERICA.COM, then you have control of a domain name that people could easily confuse with that of a major retail bank in the United States. Typosquatting and homoglyph squatting are the Achilles heel of DV certificates in general.
(Score: 2) by isostatic on Tuesday November 19 2019, @11:27PM
LetsEncrpyt and other ACME based systems make no change to that problem.
EV certificates are pointless as nobody knows what they even are.
(Score: 5, Informative) by theluggage on Tuesday November 19 2019, @05:17PM (1 child)
Its certainly non-perfect, and belt-and-braces is always better, but if your server (or DNS) gets hacked then you're pretty much fucked anyway.
LE's clearly-stated objective is to maximise the use of HTTPS, and automating the process as much as possible is the best way to achieve that (if you're a black belt in Unix its easy to underestimate how complex it was before LE, even if you could find a free/cheap CA). Some of the free/cheap/friendly CA's that emerged to fill the gap in the market before LE weren't exactly making the web a better neighbourhood, either...
Bottom line, though, HTTPS is a great example of putting a steel door on a tent - strong encryption isn't worth much without strong identity verification to back it up, and you're not going to have the latter if you still want to anonymously buy certificates without physically visiting a notary public's office with three forms of ID and a DNA sample. Then we have browser makers hugely overselling the security of HTTPS, making it ever harder to actually see the certificate and killing off "extended verification" (which, frankly, ought to be a pre-requisite for any sort of financial transaction), plus businesses etc. using "www.outsourced.services.com?how%20the%20fuck&am_i_supposed_to_know=thisIsntPhishing&redirect=realcorp.com" type URLs... (please don't click on that link, that domain is bound to exist).
(Score: 0) by Anonymous Coward on Wednesday November 20 2019, @12:50AM
Two things. First, always use the ".example" or ".invalid" TLDs in your examples to avoid that problem in the future.
Second, because I couldn't resist, https://urlscan.io/result/32d07d2d-5930-408f-b2fd-19f5e97122dd [urlscan.io] shows that name doesn't resolve and https://urlscan.io/result/654c13ed-44c2-406d-921f-1e26f4d576f1 [urlscan.io] that the base domain redirects to an Oracle website.
(Score: 3, Interesting) by Thexalon on Tuesday November 19 2019, @08:15PM
Here's why that doesn't matter: What existed before Let's Encrypt was a system where if you had an identical level of control of a webserver (you need to be able to write to the webroot, and alter the configuration of the webserver, e.g. /etc/nginx or /etc/httpd), you could replace any existing SSL certificate with one of your own, and MITM the server for up to 2 years before anybody noticed.
I think you made the mistake of thinking that the lowest-grade SSL certificates did anything more than take your money and determine that you were capable of putting files in the webroot directory of a server they reached by DNS. And of course admins with a large set of servers to manage would semi-automate this process as much as possible. The only people who really benefited from that system were schlock certificate signers, who basically got to charge every year to run an extremely simple service that most Soylentils could code up easily. And the only security benefit to doing SSL that way versus Let's Encrypt was to increase the cost of pwning you that way by the cost of paying for a certificate.
And in most practical terms, all of this is moot, because most people have their webserver configuration root-writeable only, and if a black hat who has the slightest clue what they're doing has root temporarily, they have root permanently.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by The Mighty Buzzard on Wednesday November 20 2019, @02:07AM
Yes, it is. Even permanent users with non-elevated privs can't do fuck-all with webroots, can't open a port on 80 or 443 if you're not running a webserver already, and can't add TXT entries to your domain's zone in your DNS server if you're using DNS challenges. And they have no read access to the directory you're storing your certs in unless you are a moron of epic proportions.
My rights don't end where your fear begins.