Let's Encrypt has announced the generation of root and intermediate certificates, share the public keys, and show the layout of their operational structure. The keys are RSA (the Rivest, Shamir, and Adleman algorithm) for now with ECDSA (Elliptic Curve Digital Signature Algorithm) versions coming later this year.
The root certificates are for the Internet Security Research Group (ISRG) and separately for the Online Certificate Status Protocol (OCSP) for the ISRG. OCSP is described in RFC 6960 and used for revocation of certificates.
The intermediate certificates are for two different intermediate Let's Encrypt CA (Certificate Authority) servers named/numbered X1 and X2. These are cross-signed by the IdenTrust root CA for ease of deployment and use by existing browsers without the need for any modifications until the browsers add the ISRG root CA through updates. The Let's Encrypt intermediate CA X2 is only intended for disaster recovery in case of a non-functional X1. The Let's Encrypt announcement has a schematic of the structure.
The target is (or was) to launch the Let's Encrypt service in the second quarter of 2015 (which ends this month) and they plan on further announcements during the next few weeks.
Original Submission
Related Stories
After much work in background and previous update covered here at soylentnews, the guys over at Let's Encrypt have finally given a launch schedule:
Let’s Encrypt has reached a point where we’re ready to announce our launch schedule.
- First certificate: Week of July 27, 2015
- General availability: Week of September 14, 2015
While this is a bit off from the original mid-2015 launch date, it's a great start towards encrypted web communications.
Original Submission
Josh Aas of The Internet Security Research Group reported on September 14:
Let's Encrypt passed another major milestone by issuing our first certificate. You can see it in action here
Our cross signature is not yet in place, however this certificate is fully functional for clients with the ISRG root in their trust store. When we are cross signed, approximately a month from now, our certificates will work just about anywhere while our root propagates. We submitted initial applications to the root programs for Mozilla, Google, Microsoft, and Apple today.
We're thrilled to finally be a live [certificate authority]. We'll be working towards general availability over the next couple of months by issuing certificates to domains participating in our beta program. You can request that your domain be included in our beta program by clicking here.
If you want to get involved with Let's Encrypt, please visit this page.
See our prior coverage: EFF Offers Free Certificate Authority to Dramatically Increase Encrypted Internet Traffic, The "Let's Encrypt" Project Generates Root and Intermediate Certificates, and "Let's Encrypt" gets a Launch Schedule.
El Reg reports:
Hoping to expand the pool of Let's Encrypt testers, TrueCrypt audit project co-founder Kenneth White has run up a set of scripts to automate the process of installing certificates under the Mozilla-backed open CA.
White, co-director of the Open Crypto Audit Project, has posted the work at Github, here. He explains that the project is quite simple, consisting of Python scripts to "stand up the official Let's Encrypt certificate management ACME client tool" in the target environments.
These include Debian, Amazon's Linux (for AWS), CentOS, RedHat, and FreeBSD.
[...]White says [...] the official client "can be fragile and error-prone on some systems".
Having had to batter his own head against the client, White [...] says he cleaned up the process in his scripts to make Let's Encrypt more accessible to other users.
He warns against running either the Let's Encrypt client or his scripts in production systems:
"LE is still in beta and has some rough edges", White notes, "including silently invoking sudo and installing quite a few development packages".
Previous: The "Let's Encrypt" Project Generates Root and Intermediate Certificates
Let's Encrypt Has Issued Its First Gratis SSL/TLS Certificate
(Score: 3, Insightful) by frojack on Wednesday June 10 2015, @02:35AM
I've been waiting for this to get off the ground.
It will be interesting to see if their certs will be blessed by all the other guys or they are going to give them the same cold shoulder they gave self signed certs (except Google's of course).
No, you are mistaken. I've always had this sig.
(Score: 0) by Anonymous Coward on Wednesday June 10 2015, @03:04AM
Thanks to Snowden, word is out that there is a peeping-tom in town.
And everyone is pulling their blinds....
(Score: 5, Interesting) by sigterm on Wednesday June 10 2015, @02:48AM
The ISRG Root CA uses a 4096 bit RSA key, which is likely to be resistant to brute-force attacks for the foreseeable future, unless someone actually manages to build a relatively large quantum computer. However, I was a bit surprised to learn that for some strange reason, the intermediary CAs have been issued 2048 bit keys.
Sure, 2048 bit RSA keys are expected to hold up against attacks until around 2030, assuming nobody discovers a weakness in RSA in the next 15 years, AND no major, unexpected advances are made in parallel computing in the same time period. Now, that's a pretty big assumption, and I'm not sure I'd want to bet my business on it.
But the surprising bit is that there's so little to be gained by using 2048 bit intermediary keys as opposed to 4096 bit keys, as long as the Root CA is using a 4096 bit key anyway. If a device can't handle a 4096 bit RSA key, it won't be able to validate the certification path regardless of the length of the key used by the server or intermediary CA, as long as it points back to a root with a 4096 bit key.
Well, a key that's half as long is going to be significantly easier/faster to validate, but even with a 4096 bit key, a modern CPU is still able to perform a few thousand validations per second. And you'd only have to validate a certificate once every time you visit a web site, since SSL/TLS re-uses existing encrypted connections for consecutive requests to the same server.
(BTW, the root certificate is valid until 2035, so why not go a bit overboard and use a 8192 bit key, just to be absolutely sure? Oh yeah, that's right; Apple broke 8192 bit key support back in 2006: https://discussions.apple.com/message/3650856#3650856 [apple.com] ...and they still haven't fixed it: https://discussions.apple.com/thread/3961444 [apple.com] )
(Score: 3, Interesting) by frojack on Wednesday June 10 2015, @03:13AM
But does it really matter?
Lots of people thing SSL is pretty much owned by the NSA and GCHQ.
http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security [theguardian.com]
http://www.theregister.co.uk/2011/04/11/state_of_ssl_analysis/ [theregister.co.uk]
http://blog.cryptographyengineering.com/2013/12/how-does-nsa-break-ssl.html [cryptographyengineering.com]
No, you are mistaken. I've always had this sig.
(Score: 3, Informative) by sigterm on Wednesday June 10 2015, @03:31AM
SSL is not necessarily "owned" by NSA, GCHQ or anybody else, unless we use weak/flawed cryptographic algorithms/software. In fact, the articles you provided links to, explains this: An adversary will need to steal keys, use side-channel attacks or issue fraudulent certificates (for use in Man-in-the-Middle attacks) in order to efficiently decrypt SSL traffic.
A short key on an intermediary CA makes the latter scenario more plausible. A successful attack against an intermediary CA key will not help an attacker decrypt traffic to/from an end entity, but it will enable the creation of fraudulent certificates.
So while the NSA may use National Security Letters to strong-arm the Let's Encrypt initiative into issuing a fake certificate for a specific MitM attack regardless of key size, a short key size could make brute-force attacks possible, and then everyone with access to sufficient computing power could issue fake certificates for any domain.
(Personally, I'm not all that worried about the Chinese or the Russians reading my emails, since unlike the NSA/CIA/GCHQ they don't have the power to arrest or "disappear" people in the western world. But when it comes to encryption backdoors in general, I really don't think the principle of "the more, the merrier" applies, hence I'd like keys to be longer than just the bare minimum required as of right now.)
(Score: 2) by Gravis on Wednesday June 10 2015, @04:48AM
SSL is not necessarily "owned" by NSA, GCHQ or anybody else, unless we use weak/flawed cryptographic algorithms/software.
"not necessarily" is just pedantry. when it comes to encryption, it's either secure or it's insecure (aka owned).
check out this wikipedia chart [wikipedia.org]. SSL 2.0 and SSL 3.0 are both insecure and have been replaced with TLS.
(Score: 0) by Anonymous Coward on Wednesday June 10 2015, @07:17AM
The thing is, SSL does not care which CA issued the certificates. So even if you choose the most trustworthy Norwegian CA, the NSA can just get their fraudulent certificates from a different one.
Check the list of certificate authorities your browser accepts by default. It's huge. Any of them can issue certificates for any domain. Rumor has it that two of those actually are the NSA. And even if not, every single one that is in the USA can be used via National Security Letters. And the CA is not allowed to tell anyone when this happens.
Still looking at the list? Ok, now look for China. They can do the same thing, and they probably don't even need a National Security Letter to do it.
SSL is broken by design, and cannot be fixed. We need to start over.
(Score: 2) by Yog-Yogguth on Friday June 26 2015, @11:25PM
This is a late reply/comment (desperately trying to catch up, only now have I started reading the comments to my own submission) and /I don't disagree with you at all/ but just in case Norway wasn't used as a random $country or in case somebody mistakenly thinks there's anything particularly good or better going on there I wanted to point out —not only— that Norway is a Nine Eyes member but that recently there's been something odd going on there:
TL;DR: don't count on Norway :(
Bite harder Ouroboros, bite! tails.boum.org/ linux USB CD secure desktop IRC *crypt tor (not endorsements (XKeyScore))
(Score: 2) by VLM on Wednesday June 10 2015, @03:24PM
unless we use weak/flawed cryptographic algorithms
Isn't it known to be broken by everyone? Big Bro shows up with a NSL says all your data belongs to us; including live; send bill for time to this address?
The only use I know of that isn't broken so far for https is idiot marketing people buying 50 domain names for one company and putting https on all of them. Paypal is famous for this, there's some paypalstories dor com or something like that BS marketing site or something which is possibly the only you'll see a URL out on the scam-ternet that claims to be, and actually is, paypal, and yes that one site is legit with a verified paypal.com SSL cert?
Every other possible attack group either powns the server, powns the browser, powns the OS, powns the corporate legal dept with a NSL ... There's not many attack vectors left for non state bad guys to use.
(Score: 2) by hendrikboom on Wednesday June 10 2015, @02:53AM
What is the "Let's Encrypt" project, and what's different about it?
-- hendrik
(Score: 5, Informative) by sigterm on Wednesday June 10 2015, @02:59AM
It's a Certificate Authority that can issue server certificates to web servers and mail servers, just like StartSSL, VeriSign, GoDaddy and others. The difference is:
a) Unlike VeriSign and GoDaddy (but like StartSSL), the certificates are free, and
b) Unlike everybody else, the Let's Encrypt initiative has developed a fully-automated solution
If you own a domain name, you can get a certificate for free using just open network protocols. Renewals can be done automatically as well. That really is a big deal.
(Score: 0) by Anonymous Coward on Wednesday June 10 2015, @05:28AM
Although, looking at the tools - written in Go, using Docker.. This "fully automated" solution sounds like a hack, or at best something that works on Docker-enabled Linux distributions only.
Quite limited.
They're re-implementing all the tools to generate certificates and keys and so on, so it will take a few years for bugs and security issues to be ironed out.
This is not the promised land... yet.
(Score: 2) by frojack on Wednesday June 10 2015, @05:24PM
What is the "Let's Encrypt" project, and what's different about it?
AH, would have been great if the submitter had thought of your question.....
The one link answer:
Follow this link to the explanation page: https://letsencrypt.org/2014/11/18/announcing-lets-encrypt.html [letsencrypt.org]
But also:
Historical time line Here in Wikipedia [wikipedia.org].
No, you are mistaken. I've always had this sig.
(Score: 0) by Anonymous Coward on Wednesday June 10 2015, @03:40AM
Still haven't signed up for a Soylent account yet, I suppose I should while the gettin's good, but...
Anyway, cursory inspection shows that the primary key servers will still be located in California, or at least the USA. Won't this be a problem for obvious reasons? Or am I missing something?
(Score: 0) by Anonymous Coward on Wednesday June 10 2015, @03:52AM
To add to this, being someone who is hardware rather than software educated, how does this help the average internet user?
(Score: 2) by dyingtolive on Wednesday June 10 2015, @05:21AM
By my bleary, past my bedtime comprehension: In theory, it would remove the cost of entry barrier for https connections. To the end user, it could make it so that it doesn't pop up scary warnings about self-signed certs on your browser/mail client. As such, you could also literally encrypt "the web".
Don't blame me, I voted for moose wang!
(Score: 0) by Anonymous Coward on Wednesday June 10 2015, @07:32AM
Mozilla (developers of Firefox) has decided that everybody must use HTTPS, although the security underlying HTTPS is broken by design (any CA can create a certificate for any domain, so all e.g. the NSA needs to do is create their own certificate for your domain to MITM any connection to your server).
The only point in HTTPS is to extract money for certificates. But Firefox is supposed to for the free and open web, so they can't be seen doing that. This project is simply to give you certificates for free, so you can keep running your server after Firefox starts demanding HTTPS.
That this makes the whole HTTPS only thing a pointless exercise seems to have gone right over their heads. The only possible explanation I can see is that corporations likely won't be using these free certificates, so when they are forced from HTTP to HTTPS (not every corporation is a web shop), they will be paying for authentic Verisign certificates.
(Score: 5, Insightful) by sigterm on Wednesday June 10 2015, @03:57AM
You're just missing one piece of the puzzle: that the Public Key Infrastructure on the Internet is vulnerable to attacks from governments and bad actors with access to ANY generally-trusted Certificate Authority.
If the Let's Encrypt initiative was hosted on Iceland, the NSA could still obtain a fraudulent certificate from any of the other CAs in the world, several of which are in the US of A and falls under their jurisdiction.
The main problem with PKI is that there's no way to limit the authority of a CA. You either trust it implicitly, or you don't. It would be nice if a CA could be restricted to just a section of the DNS namespace (for instance, why should a Chinese CA be allowed to issue certificates to .gov domains?) or prevent a CA from issuing certificates to domains which already have valid certificates from another CA, but sadly this just isn't possible under the current system.
(Score: 0) by Anonymous Coward on Wednesday June 10 2015, @06:53AM
I think most of us around here know this already, and I run Perspectives (not that it seems to help since their servers crash all the time and several sites like Google use so many certs as to not be trackable). There was that one project (Convergence? something like that) but it seemed to die from lack of interest.
Sooooo...the billion dollar question (literally, I think): what do we replace PKI with?
(Score: 0) by Anonymous Coward on Wednesday June 10 2015, @07:10AM
However it needs some improvements like support for multiple certs per site (some sites use many different certs).
Perhaps one day I'll try to see if I can add the feature myself, but I'm not an expert so...
(Score: 0) by Anonymous Coward on Wednesday June 10 2015, @08:44AM
Yes, the CA system is broken, but
(Score: 0) by Anonymous Coward on Wednesday June 10 2015, @07:19AM
It doesn't matter. Any CA can create certificates for ANY domain, so as long as even one CA is in the USA (or the UK or China), the whole system is broken.
(Score: 4, Interesting) by NCommander on Wednesday June 10 2015, @06:45AM
I've never heard of them before, but if this pans out, I know who's going to be signing soylentnews.org's next SSL certificate. When they fully go live, I'll replace dev.soylentnews.org's self-signed certificate as a trailrun (as well as implementing HSTS and HPKP there in the nearish future).
Still always moving
(Score: 2) by kaszz on Wednesday June 10 2015, @04:18PM
Unless there's a control panel in the browser to permit the user to declare which CA that has permission to issue a certificate for which site(s) in a firewall style control list [soylentnews.org]. The SSL/TLS CA system will still be wild-wild-west. In addition fingerprint pinning should be a default capability.
Also any CA violating this permission list should alert the user immediately. And users need multiple sources of CA revocation lists. Any CA with legal or HQ placed within the three current superpowers is broken by default assumption.
(Score: 2) by NCommander on Wednesday June 10 2015, @10:02PM
HPKP solves the problem IMHO much better. The site tells the browser which keys or certificates that are allowed to sign it. The CA is reduced to establishing the trust of the first connection from the browser, afterwards, it doesn't play much of a roll in ongoing security. HPKP/HSTS preloading in browsers allow sites to be stapled in advance of that first connection. In case of mismatch, the browser refuses to complete the TLS connection. Once rehash fully stablizes and I work out all the logistics, we'll be rolling it out here.
Still always moving
(Score: 2) by kaszz on Friday June 12 2015, @12:59AM
But if the site is MITMed then it can tell your browser that "hey that sleazy CA there is fine for signing this bogus site!" ..
Browser based permission list is probably preferable because it will set a firm limit on any CA.
(Score: 2) by NCommander on Friday June 12 2015, @06:17AM
Once you make first connection to the site, the HPKP and HSTS data is stored, and can not be changed unless it ages out, or the browser sees a new header on a TLS connection created with a pinned key. If its preloaded in the browser, then its always good. Short of a TLA successfully hijacking one of the pinned keys, MITM is impossible with bog standard browsers which support these two protocols. The only downside is HPKP is new, and I don't think offical support has trickled down in Firefox (yet). Chrome supports it in the latest stable if I remember my research correctly. IE doesn't.. Without the specific certificate *or* key (depending on what is pinned), the connection is refused. While I think CAs should have some scoping rules, how are you going to explain to most folks a site broke and they have to change their CA "firewall" (for want of a better term).
You're going to have certificate authorities in the United States that will have authority to sign stuff in the com/net/org zone. Even if you blacklisted all the government run CAs, a warrant could easily get them a valid cert that matched your firewall.
Still always moving
(Score: 2) by kaszz on Friday June 12 2015, @08:11AM
But it would force them to use a CA outside of their jurisdiction to get a matched CA outside of com/net/org/us. Which complicates matter for them a lot more. And even then, there's no telling which of those CAs that are allowed to sign anyway. Because the domain space may be further partitioned by a user.
But at the core of it. It's complete backwards that the Chinese government can sign certificates for US banks and similar situations.