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.
Related Stories
The EFF will be offering free CA to people to help the web move to HTTPS from HTTP. This will be launching in 2015.
EFF is pleased to announce Let’s Encrypt, a new certificate authority (CA) initiative that we have put together with Mozilla, Cisco, Akamai, IdenTrust, and researchers at the University of Michigan that aims to clear the remaining roadblocks to transition the Web from HTTP to HTTPS.
Although the HTTP protocol has been hugely successful, it is inherently insecure. Whenever you use an HTTP website, you are always vulnerable to problems, including account hijacking and identity theft; surveillance and tracking by governments, companies, and both in concert; injection of malicious scripts into pages; and censorship that targets specific keywords or specific pages on sites. The HTTPS protocol, though it is not yet flawless, is a vast improvement on all of these fronts, and we need to move to a future where every website is HTTPS by default.With a launch scheduled for summer 2015, the Let’s Encrypt CA will automatically issue and manage free certificates for any website that needs them.
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
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
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: 1, Offtopic) by Non Sequor on Saturday September 26 2015, @11:23PM
I'm calling it.
Write your congressman. Tell him he sucks.
(Score: 0) by Anonymous Coward on Sunday September 27 2015, @03:50AM
Can you be the slightest bit specific?
-- gewg_
(Score: 2) by fnj on Saturday September 26 2015, @11:32PM
What is taking so goddam long?
(Score: 0) by Anonymous Coward on Sunday September 27 2015, @03:54AM
Lord, give me patience--and I need it RIGHT NOW!
-- gewg_
(Score: 2) by jmorris on Sunday September 27 2015, @12:04AM
Is the point of this project to end the basic HTTPS on the grounds it is already untrustworthy and to finally make it so obvious that even idiots start to realize it?
Is it a marketing front for the enhanced certificates?
Or what?
(Score: 2) by opinionated_science on Sunday September 27 2015, @12:40AM
I agree, I'm not sure what I am missing too? Surely depending on some or any trusted place for a certificate is the problem with the whole system.
This, of course, is the govt and their national security letters since they can compel any company to sign, whatever...
(Score: 5, Informative) by Justin Case on Sunday September 27 2015, @12:47AM
If I understand it, a bunch of companies built their business model around accepting some bits, running them through an algorithm, and selling the output bits at an outrageous multiple of the cost of electricity required to do so. (https certificates)
Millions of "web masters" (I use the term very loosely) used this cost as an excuse not to use https.
Meanwhile, asshats worldwide are corrupting http traffic to inject malware or ads (which are basically just malware targeted at your eyeballs instead of your CPU). So anyway, EFF (they're the good guys remember?) said let's take away the excuse that "I can't afford https" by making it free in hopes of a mass switchover, to the eternal frustration of the aforesaid asshats.
Of course, I didn't read TFA, but perhaps a clue can be found in one of the summary's links: EFF Offers Free Certificate Authority to Dramatically Increase Encrypted Internet Traffic [soylentnews.org]. I mean, an informative link... it could happen, right?
(Score: 3, Funny) by jmorris on Sunday September 27 2015, @01:46AM
I have read the propaganda. I'm talking about what their actual goals might be since their means clearly cannot possibly achieve the stated one.
If these root certs get accepted into mainstream browsers there is zero trust left in the basic https transaction. My ISP (suddenlink) is already poisoning DNS so they can try hijacking traffic on a massive scale. It just doesn't work though so you get no Internet unless you override their DNS and use another. At least FF on Linux doesn't work, all I was getting was certificate errors as every site had a trust chain involving suddenlink.net. Once nobody trusts basic certs and more important a total trojan horse like this is in every browser, something this scheme implies, they CAN force browsers to accept their certs, they can use this to sign a cert for any site, hijack https traffic and inject it. At which point only the enhanced certificates will mean anything. Webmasters balked at paying godaddy $10 for a cert, wait until they see the pricing and paperwork for enhanced certificates.
(Score: 5, Insightful) by Anonymous Coward on Sunday September 27 2015, @03:19AM
You assert two things. 1st, that Let's Encrypt somehow allows your ISP to generate a valid certificate for any domain. 2nd, that this will make things worse. I'm going to address the 2nd one somewhat at length and in non-technical terms, not so much for you as for others who may read it, then come back to the 1st one in the last paragraph -- skip down there if you like.
Look, https attempts to solve two problems at once:
Only 2. requires any trust -- in fact, there's a trust-free way to use a https for 1. only. It's called a self-signed certificate, and it's been made practically impossible to use, because browsers flip the fuck out about it -- they treat it as worse than http, and users get confused and scared. At worst, LE (Let's Encrypt) gives the same results as a self-signed certificate, only without the browser freakouts -- which is basically what it's meant to do.
But enough about that, let's talk about 2. Authentication, and the trust it implies. Problem is, any CA can sign a certificate for any domain. So let's say I get a certificate from HonestCert for my domain. Someone else pays ShadyCert to give them a certificate for my domain, and throws in a little extra to "overlook" checking who owns that domain. Or if CarelessCert's server gets pwned, and the hacker absconds with their private keys, the hacker can generate and sign his own certificate for my domain. Unless and until ShadyCert and CarelessCert are publicly known to be untrustworthy, and browser vendors remove their root certificates, and each user updates their browser's data, all these certificates make the three of us look equally valid.
In short: as long as any CA trusted by browsers currently in use can be subverted, all https traffic is vulnerable to MITM with a certificate from that weakest-link CA. (An obvious solution to this is to let the domain owner specify a CA or list of CAs, and to only accept a certificate that is signed by a CA on that list -- If I only list HonestCert, then neither ShadyCert nor CarelessCert certificates will be accepted. As long as DNS isn't compromised, it's a suitable method for specifying the list.)
As long as https is based on this any-CA scheme, and thus as trustworthy as the weakest-link CA, there's already zero trust -- the only benefit left is encryption, so we're better off with everything encrypted and still not trustworthily authenticated, than the present situation where a little is encrypted and nothing is trustworthily authenticated.
--
As for LE enabling your ISPs MITM... just WTF? Perhaps you should read LE's technology page [letsencrypt.org], but in short, they replace the usual step of proving domain control with an email to e.g. webmaster@example.com (if you can read that email, you are presumed to control example.com) with a bit of software running on your server and communicating with ACME (Automated Certificate Management Environment) protocol. To use this to generate a certificate to MITM example.com, your ISP must either pwn the example.com webserver and install an ACME client on it, or (b) MITM the traffic between LE's ACME server and the example.com webserver. If they can do that anyway, they don't really need LE's help!
(Score: 1) by Pino P on Sunday September 27 2015, @04:58AM
An obvious solution to this is to let the domain owner specify a CA or list of CAs
Better yet, make a DNS record the CA. DANE (RFC 6698) [wikipedia.org] lets a domain owner specify in DNS which CAs work in a domain or even include a root CA directly in DNS. For example, in a browser supporting DANE, if the viewer's DNS server supports DNSSEC, you can specify that your domain will use only HonestCert. Both Chrome and Firefox have DANE extensions. But this still doesn't protect you from CarelessRegistrar.
(Score: 0) by Anonymous Coward on Sunday September 27 2015, @04:48PM
Yeah. It's not like lots of ISPs hijack DNS already, returning advertising/search pages for nonexistent domains. How hard do you think it would be for them to hijack valid DNS requests with DANE and replace them with MITM-enabling DANE/DNSSEC results?
(Score: 0) by Anonymous Coward on Sunday September 27 2015, @06:27PM
It would be hard. DNSSEC signs all of the records recursively. For example, to fake the DANE keys for www.example.com, they would need to generate said fake DANE keys, sign them with the www key, sign that with the example key, and sign that with the com key. Some adversaries may be able to pull that off on targeted attacks, but I doubt ISPs can.
(Score: 1) by Pino P on Sunday September 27 2015, @04:42AM
MITMing HTTPS at this scale is something I've only seen in three places: corporate firewalls, captive portals on free Wi-Fi to redirect viewers to the TOS page, and Suddenlink [arstechnica.com]. If your ISP is MITMing every single connection you make even with Google and Comcast (8.8.4.4, 75.75.76.76, 8.8.8.8, 75.75.75.75) set as your DNS, and the ISP doesn't offer a different service level that lacks this proxying, you need a different ISP.
(Score: 3, Interesting) by jmorris on Sunday September 27 2015, @06:51AM
Suddenlink does not block access to Google's public DNS, which was the solution i picked. There are effectively no other ISP options since they added this crap along with dropping a nuke on the DSL option from AT&T. They made base level service 50mbps down/5mbps up. with upsales to 100 and 150mbps. Contrast to the 6mbps/512kbps max offered here on DSL. Some select areas are starting to light up some fiber with Userve so there is longterm hope but AT&T are also rat bastards.
Hope folks understand my paranoia here, hijacking https isn't a theoretical future menace for me, it is happening now. I suspect anyone dumb enough to install the 'easy setup CD' or whatever Suddenlink wants new subs to run is already completely compromised. Any scheme that might possibly make it easier is something I will oppose. Others here say that while LE hands out certs with no verification they have some mechanism to prevent the wholesale abuse I'm worried about. That it can sign a cert on the fly for 'any' domain but can somehow verify it is only doing it for the rightful domain owner. Ok, maybe. Still don't see the upside though so why are browser makers going to add their root cert?
Don't give me this Snowden/Ron Paul paranoia about the man watching so we have to encrypt everything even if we basically discard the authentication part of https. The man has already been seen happily encamped at the server side of every major site so they don't need to snoop the traffic in transit, they just log into Google's own servers and access whatever they damned well want. The threat is from the ISPs at the last mile and tech probably isn't the answer. Threatening to remove their monopoly is the only hammer scary enough to get their attention.
(Score: 2, Insightful) by Anonymous Coward on Sunday September 27 2015, @11:14AM
Don't give me this Snowden/Ron Paul paranoia about the man watching so we have to encrypt everything even if we basically discard the authentication part of https. The man has already been seen happily encamped at the server side of every major site so they don't need to snoop the traffic in transit, they just log into Google's own servers and access whatever they damned well want.
And don't give me this whole "The government isn't the real threat..." and "Security is all or nothing!" nonsense. Mass surveillance will destroy our freedoms and what little democracy we have. The government has more power to destroy you than anyone else, which isn't to say corporations aren't bad too. Even if you're not being personally targeted, you should still want to defend the rights of those who are (whistleblowers, dissidents, etc.). None of this is paranoia, but a recognition that power corrupts, which is a fact that has been proven by every single government throughout history without exception. The US government itself has proven this countless times. I see paranoia as believing everyone is out to get you personally, whereas this is more about concern for society as a whole, with the recognition that your own individual rights are also being violated.
Security isn't all-or-nothing. Just because this doesn't completely solve the problem doesn't mean we should make it even easier for the government to spy on us. They have to do more work to perform mass surveillance this way, which is what we want.
(Score: 5, Informative) by Pino P on Sunday September 27 2015, @04:31AM
An X.509 certificate contains a public key, information about a person called its "subject", and a digital signature from a certificate authority (CA). A Transport Layer Security (TLS) certificate is an X.509 certificate that identifies the subject as the operator of one or more servers whose hostnames are listed as subject alternate names in the certificate.
In TLS, a CA's job is to certify that its subject, and not a man in the middle (MITM), controls a particular set of hostnames. Consider the following increasing levels of assurance:
A self-signed certificate assures you that the subject you're talking to is the same subject you talked to previously. But because it cannot secure the first communication with a particular subject, web browsers generally display a warning interstitial for a self-signed HTTPS site, with a multi-step procedure to dismiss it. They justify an interstitial for self-signed with no interstitial for plain old HTTP by claiming that the use of the https: scheme with self-signed certs provides a false sense of security, while http: provides a true sense of insecurity.
Some CAs offer DV certificates, which contain very little information about their subjects other than that they control hostnames. A DV certificate doesn't say much, but it still offers clearly better privacy guarantees than plain old HTTP. This is the level of assurance provided by free CAs StartSSL and WoSign as well as low-end products of paid CAs. Let's Encrypt is intended to bring the DV level of assurance to everyone without charge, using the ACME protocol to automate a process similar to that used by better-known CAs to validate a domain.
There are a couple other ways to validate domain control without going through a CA, but they require specific support from the web browser. DANE is a means of storing public keys in DNS that is signed through the DNSSEC chain. The Perspectives project offers a browser extension that brings self-signed certificates to an assurance level close to that of DV certificates by using route diversity to discover MITM through differences in the certificates seen by multiple trusted notary servers across the Internet. Unlike these, Let's Encrypt works in today's browsers without add-ons.
There are two levels of assurance on top of this, offered by more expensive CAs. These include OV, which includes the name of the subject company, and EV, which also includes the complete address of the subject company as well as its business category and tax ID. Browsers are likely to present stronger trust indicators in the address bar for sites using these certificates. In fact, the Comodo Dragon browser has displayed interstitials for domain-validated sites similar to the typical interstitial for self-signed sites. This is presumably intended as a measure against typosquatting, as he who registers bankofamerrica.com with two R's controls bankofamerrica.com even if he is not authorized to speak for Bank of America Corp. But it can be seen as a conflict of interest, as Comodo sells certificates with organization or extended validation.
What "untrustworthy" aspect were you referring to? The possibility of typosquatting and fooling DV, or the possibility of fraudulently passing OV or EV diligence?
(Score: 4, Interesting) by darkfeline on Sunday September 27 2015, @03:46AM
I think SSL/TLS would've been better off with a web-of-trust model like PGP. Centralized trust simply doesn't work very well, and not to mention is inflexible (for example, centralized trust is the same as ultimately trusting a given key in PGP, but you cannot implement PGP trust in SSL).
That way, plebeians (I say that somewhat affectionately) can trust their web browser/Google/the government's key, and the paranoid can choose to partially trust, say, the EFF's and FSF's keys.
The web of trust is also redundant in case any small proportion of keys are compromised, just revoke them and move on.
Join the SDF Public Access UNIX System today!
(Score: 0) by Anonymous Coward on Monday September 28 2015, @12:35AM
I don't know about you, but my OS lets me choose to trust or distrust certs, or add and delete them, including centrally issued roots. Distrusting them has consequences, as it will break a lot of websites. I can also trust whichever key I want, such as the EFF or FSF keys, by grabbing the key and putting in the keychain and marking it "Always Trust" for certain contexts like SSL or SMIME or whatever.
Apple did a good job on Keychain.
(Score: 3, Informative) by darkfeline on Monday September 28 2015, @08:49PM
I don't think you understand the full picture.
X.509 certificates can only be signed by one key. Say Google, Wikipedia, Facebook and Bank of America all buy certs from company A. If company A's key is compromised (which does happen), Google et al's websites are now all compromised, period. There is no failsafe.
If we instead used a PGP-like model, Google et al would all have their certs signed by companies A, B, and C. Even if A's key is compromised, Google et al's websites are still known to be trusted if they are signed by B and C who are not compromised. Then when A gets their key replaced with A', they can re-sign Google et al's certificates using A'. Redundancy during failure, just like RAID.
Furthermore, you can extend trust from other people. Say you're a tech-illiterate dummy, but you have a deeply trusted friend who works in security. You can just ultimately trust his key, and then automatically benefit from his knowledge. Say he has audited companies A, B, and C, and he knows A and B are secure while C is a leaky basket, now you know that too via his public key.
(In the interest of full disclosure, I think there are ways to "sign" X.509 with multiple keys, but I'm not familiar with the details.)
Join the SDF Public Access UNIX System today!