If you have secrets that are too sensitive for community trust, there are other mechanisms, but they typically have trouble scaling very much beyond continuing a previous face-to-face relationship. For the question of whether, say, news.ycombinator.com is who they say they are, I don't care enough to take Caltrain down to YC's offices and check a fingerprint posted on the wall, if they had one. What I care is that, at scale, the certificate authorities I trust will do a good job of verifying identities and running secure systems.
And I am not an auditor or pen-tester of large companies, and even if I were, I wouldn't want to spend my spare time auditing and pen-testing all CAs just before I can use the internet. (Importantly, I am not an auditor of web browsers or SSL implementations either, and since I outsource my trust to my browser / SSL stack, it's not useful for me to be skeptical of the CAs unless I'm also skeptical of the code.)
Remember that the CA model is bare-minimum security. (Some of the CAs find money in telling you otherwise, but they're stretching the truth.) All it's providing is the security that, in a perfect world, you would have gotten all along from DNS and IP. If you need anything more than bare-minimum security, there are tons of options, ranging from the SSL-based (EV, HPKP) to the completely unrelated (PGP, Pond, etc.). But the world needs a good mechanism for the simplest security that could possibly work, and the CA system seems to have settled into that role.
Some Mesh Networks & protocols like the Tor Browser use an IP derived from a public key.. so you're absolutely sure that who you're talking to is who they say they are.
Why can't we have our cake (long distance electronic communications) and eat it too? (encryption & assuredness of identity)
Celebrating "trustedness" of LetsEncrypt only perpetuates the belief that CA is working fine.
EDIT: See below discussion by other posters
This is what is wrong with the CA, model, not their method of announcing it to a community anxiously awaiting the arrival of their product. What is absurd is that identrust has a shitty non-responsive 90's looking website and wants $299 for an SSL certificate, which is something that should be free. I will say though, they really did sell me on their trust worthiness with the alternating images of a fingerprint and a lock. So now I know they're legit. It is worth the $99 for SSL on a single site annually because there is binary data superimposed on some of the pictures.
In this case, B is LetsEncrypt and is (hopefully) pretty solid, but that isn't always the case. Earlier this year, it became known that CNNIC had issued a CA cert to MCS Holdings (of Egypt), which then did bad things.[1]
The news that everyone is suddenly trusting a new entity B, whether it's some Egyptian IT firm, or LetsEncrypt, comes out of nowhere. Neither cooperation nor even awareness is needed of the major browsers' dev teams.
[1] https://googleonlinesecurity.blogspot.com/2015/03/maintainin...
https://helloworld.letsencrypt.org/
Nice work team!
Really looking forward to spreading HTTPS far and wide.
1: https://www.ssllabs.com/ssltest/analyze.html?d=helloworld.le... 2: https://mozilla.github.io/server-side-tls/ssl-config-generat...
https://mozilla.github.io/server-side-tls/ssl-config-generat...
They are also planning on support CT.
With a cross signed root, clients with only the IdenTrust root will validate the cert, and clients with only the LetsEncrypt root can validate the cert.
With a cross signed intermediate, the server has to guess which root the client has and serve the correct path, there's a TLS extension to indicate roots the client supports, but nothing actually uses it, so I don't know how the server is going to guess (other than to assume no one has the LetsEncrypt root, since it's new).
[1] but some clients are dumb and won't validate successfully when they reach a root they know :/ Most browsers will though.
I've attempted to maintain a list of all the providers that do (in one way or another), and it's currently 4:
* CloudFlare https://www.cloudflare.com/ssl
* StartSSL https://startssl.com
* WoSign https://buy.wosign.com/free
* Let's Encrypt https://letsencrypt.org
For people reading this comment dozens of months in the future, a maintained list will be kept at https://paragonie.com/white-paper/2015-secure-php-data-encry...
* CloudFlare doesn't give you a certificate. It terminates your TLS connection at their endpoint with a certificate they own the private key to.
* StartSSL free tier is for non-commerical use only.
* Haven't used WoSign so no idea what it is, but clicking on the link took was so laggy it didn't give me much confidence. (I personally wouldn't work with a company in China jurisdiction when it comes to security products.)
Let's Encrypt is a big step forward in having a legitimate, actual, user-friendly, free TLS certificate issuer without restrictions for usage scenarios.
Also note that free single domain certificates have been available from StartSSL for a very long time, but this didn't destroy the certificate industry.
Do you really know the difference between Citi Bank and Citibank? No? Then EV hasn't saved you from being phished.
If you are running a commercial, high-traffic website, then yes, there is.
For example, EV (extended validation) certificates is currently the only way to quickly build and maintain a "reputation" with 3rd party website ranking systems such as Microsoft's SmartScreen and, based on anecdotal evidence, with Symantec SafeWeb and Google SafeBrowsing services. Needless to say that SmartScreen is on by default in IE/Edge and SafeBrowsing is on in Chrome and, in part, Firefox.
I'd like a manual mode, as years of sysadmin work have made me extremely skeptical of tools that try to automatically modify config files.
However, as far as I understood, there is an API that will just hand out the certificate.
I guess they don't want it to be accessed by a web browser because they want us to regenerate and include a newer cert automatically.
So you have a somewhat higher setup cost (setup automatic cert update rather than one-time download of your cert), but then you can't forget to update your cert over the years.
I believe they also want this is be a fast desaster recovery. So if their main intermediate certficate is compromised, they can revoke it and hand out new certificates (using the backup intermediate cert) for all domains within a very short amount of time.
Nevertheless, I would have preferred a good explaination about how to setup this process manually, rather then depending solely on their tool.
(In case this process it too cumbersome without their tool, they should simplify it rather than hiding this in their tool.)
There is a "manual" mode, "Here is the file that you need to post, press Enter when you are ready to continue"
There is a "standalone" option. If you don't have a webserver running, it will bind to port 443 and solve the challenge for you.
There is also a "Webroot" option. Enter in your server's webroot and it will automatically post a file to .well-known and delete the file after validation.
Honestly, it is amazing to me that someone like Google or Amazon did not do this as free service a long time ago. But having an independent entity like this do it is far better.
Does this mean we can now all use Let's Encrypt to generate new certificates without people running into problems?
This does not, however, mean that we can all start using Let's Encrypt. They're doing a slow roll-out before making certs generally available to the public. You can apply for the Beta at https://goo.gl/forms/kf0IGCeAk5, or wait until general availability later this year.
When a server uses a Let's Encrypt certificate, a browser will consider it as issued under an IdenTrust root CA, which the browser trusts. So it will consider the Let's Encrypt certificate trusted.
edit: initially said SSH. I blame the plane wifi
How is this beneficial for IdenTrust?
It establishes IdenTrust as a more influential leader of SSL certificates on the Web. There are other ways CAs can make money, and this extra publicity will probably serve them well.
If someone needs to create a fake CA/public key, they have to hack multiple trusted sites.
It is not current https sys design, but would it be more secure?
What steps are left now? :-)
Though, to be honest they do this for >90% of https sites, in my experience.
But this is kind of a good thing, because after enough attacks on the old model, people will ask for an improvement or replacement of the model.
HTTP Public Key Pinning, or HPKP, is a security policy delivered via a HTTP response header much like HSTS and CSP. It allows a host to provide information to a user agent about which cryptographic identities it should accept from the host in the future. This can protect a host website from a security compromise at a Certificate Authority where rogue certificates may be issued for your hostname.
You can read all about it: https://scotthelme.co.uk/hpkp-http-public-key-pinning/
And here are web-based tools for examining and generating HPKP hashes: https://report-uri.io/home/tools
First, this is optional software that almost every public server in the world is currently not using. It's like saying just because executable whitelisting exists that downloaded exploit payloads on operating systems is no longer a threat. If nobody uses it, the threat still exists.
In addition to actually implementing it on your server, every single user still has to make a secure initial connection over a trusted network on every device they'll ever use to get to that site.
But not every client even supports HPKP. There's lots of older software which doesn't support it, and IE doesn't support it at all, which by itself would leave 12% of all clients vulnerable.
Unfortunately the best candidate, at least for us, for supplying SCT receipts to end-users, via x509v3 extensions in OCSP responses, is currently not fully supported in Golang.
> So thus beings the transition. EV certs are going to be the only ones that get the "green" chrome in browsers anymore. Sites using standard SSL are going to get the normal no-lock/white treatment. And sites without SSL will get the caution symbol/yellow treatment.
I don't like it, but I suspect this is where we're heading.
[1] https://www.reddit.com/r/linux/comments/3pg37u/lets_encrypt_...
Are there any facts to back up this claim?
Edit: This is what HN looks like in Firefox 38.0.5: http://img4.imagetitan.com/img4/RsbN6Rsn61k2IMN/12/12_l.png
Sure, the background color is white, but there's still a padlock icon.
Final Star Wars VII trailer and LE gets cross-signed. Best. Day. Ever.
(Also: Congratulations and well done, Team Let's Encrypt!)
Second, would you prefer that browsers blessed a new CA completely independently? If not then who should have that power? Governments? Non-profit organizations like ISRG?
The big alternative is to maintain your own list of trusted CA's, going through each and every new CA that you encounter and associate a trust relationship. Not even famous security researchers do this, and I can't really blame them as it is like a lawyer reading every EULA that they encounter and fully investigate the scope of them. The scope and complexity just get beyond what a single person can manage.
I just think it's odd that any CA can turn around and make any other random CA fully blessed. It seems like it completely circumvents the browser manufacturers including root CAs at all.
Totally agreed re: maintaining your own list of CAs. I mostly do go through the system CA list and disabling any from foreign governments I don't ever plan on trusting, but that's mostly feel-good and not actual security.
You're right that this sort of broad power is scary, but I think it's being used reasonably in this context. Do you have specific concerns you are afraid of? The only problem I thought of was a compromised CA cross-signing a malicious CA, but if they are compromised, you could just issue the main CAs certs anyway.
https://letsencrypt.org/howitworks/technology/
You can only obtain a certificate for a domain if you can validate that you control the domain. Their steps for that (place arbitrary content at an arbitrary URL they request, or create an arbitrary DNS record they request) are such that, if you weren't the legitimate controller of the domain but could do those things, you wouldn't need a fake cert -- you'd already have pwned it thoroughly enough to be able to MITM it in other ways.
This isn't really a failing on Let's Encrypt though, because tons of other CAs issue certs by only verifying this exact same stuff. Certs are only as secure as the least secure CA. Since the security was already this weak, Let's Encrypt has not made it any weaker.
#1 letsencrypt blocks any request for domains which SSLObservatory (https://www.eff.org/observatory) reports as having observed a certificate, and additionally require that you show proof of possession of the private key. Every domain letsencrypt has served will also be treated with this requirement.
#2 letsencrypt will use multiple paths through the Internet. They have not given the exact details yet (I would guess that they will take different path by AS numbers).
#3 There is a block list. I don't remember the exact method used here, but I think it was simply based on Alexa rank.
Technically, you only have to make their systems think you control the domain. If their servers or 'establish proof of ownership' process are hacked, wouldn't this allow an attacker to do the same thing that happened in the DigiNotar hack?
Their technical overview explains how it works: https://letsencrypt.org/howitworks/technology/
[EDIT] I have seen this: https://github.com/ebekker/letsencrypt-win
But ideally we would want Microsoft to add a checkbox in the UI of IIS Manager, which when creating a https binding offers to use let's encrypt instead of an installed certificate.
Will definitely use this as soon as they open their doors to me.
Personally, I'm typing this post into a web site using a web browser, so I appreciate that it has a certificate that my browser can validate!
This way, Let's Encrypt in particular would need to be breached for a successful attack, while right now it's enough to breach either Let's Encrypt or any other CA.
Downloading a tool, reading man page, works out of the box only with apache/nginx - ehhh, seems like a lot of work, considering some comments touting 'user friendliness' compared to StartSSL.
The better solution is to integrate this tool into various server tools like Apache and Wordpress and in whatever else you might be running with a one-click installer.
Texas hasn't exactly got a glowing reputation in the software industry due to its mountain of intellectual property lawsuits filed by patent trolls... er, sorry, I mean non-practicing entities
Excuse me while I reserve some skepticism about just how trusted your security certificates should be.
Take for example my setup. It sits on a private NGINX server, and is proxied through a public facing CDN. Trying to simply 'switch on' TLS involves absorbing academic style tutorials from multiple disparate sources, and requires me to have a background in DevOps and that I have at least tried some technical task like this before. In layman's terms: Unnecessary Early Stage Overhead.
Now give Let's Encrypt a few more years and it will be a lot more seamless; possibly the default. It could possibly be 'baked in' to things like Softaculous, and cPanel, which are brilliant drivers for the success of web software. Digital Ocean staff are probably already working on a droplet with LetsEncrypt baked in...
Sure, someone with no devops skills at all will have a harder time, but it's for the better. Soon it will be The Way to install a webserver. Thanks to Let's Encrypt it's so easy to install TLS that nearly every future webserver tutorial will include it.
Although, it makes me even more confused as to why they used python for the official client.
I can't speak exactly to why Python was chosen, but it should be noted this isn't intended to be the be-all-end-all in terms of clients. There are already a number of other independent clients that have been developed for various different purposes.
Not to mention python is on pretty much every platform in existence by default.
If you're expecting this as a global binary like you would in go there's no reason you can't just "pip install letsencrypt"...
...except needing docker and everything running it in a docker container entails over a simple CLI.
Also, it looks like they say "for god's sake don't pip install":
Please do not use python setup.py install or ``sudo pip install`. Those mode of operation might corrupt your operating system and is not supported by the Let’s Encrypt team! https://letsencrypt.readthedocs.org/en/latest/using.html#ins...
> python is on pretty much every platform in existence by default.
....except Windows? Which also doesn't support docker.
> Why python for the client software if you obviously already have Go experience in-house? Using python means you have to run all this virtual-env crap in a bash script, apt-get install a bunch of crap for setup and not support Windows. Seems like using (nearly) dependency-free Go application for the client as well would have been a no brainer. Was it just a case of having more access to python devs, or were there other technical reasons? Anyone know? I bet this has been asked before, but not turning anything up with google.
wow what's going on here? Auto comment robot gone wrong?
The project was able to get a CA to sign their keys, this is what happened. Using the word "trust" is simply wrong and might be interpreted as a too simple kind of propaganda after we learned a lot about the untrustable nature of a hierarchical certification infrastructure.
Another, even bigger trust-breaking elephant in the room is the fact that this project is USA based - as long as US government and agencies are insisting on practices we know from authoritarian and anti-democratic states like e.g. China or Saudi-Arabia there is no way any US based project can use the word "trust" for their product description - it might be recognized as a simple lie by informed people.
Questions to the project leaders:
* you must obey US laws and therefore offer MITM access to every Let's-Encrypt "trusted" network stream - why aren't you educating your users about this serious limitation of your product?
* why don't you rebase your project to a country where a government policy exists that is allowing companies to build trustable security based products?
TLS sessions are negotiated between TLS clients and servers. Their confidentiality is guaranteed by that negotiation and the certificate authority, if any, doesn't have the server's private key and can't read the server's TLS sessions.
What CAs have the power to do is misissue certificates. Using a CA's services generally does not increase your exposure to misissuance attacks by that CA. If Let's Encrypt misissues certificates, it could misissue them for sites that are not and never have been Let's Encrypt users, just as any other CA can issue certificates for any public Internet service.
As I've said elsewhere, Let's Encrypt wants to use, and encourage others to use, technologies that limit our power to do the wrong thing, including HPKP and Certificate Transparency. We want more limits on our power and other CAs' power, not fewer, that lead to misissuance events getting caught and attacks on TLS users failing.
However, this is not free.
In return for getting an SSL certificate, your users will need to trust an organization to protect the secrets they share with you and vice versa. This organization has no economic incentive to do good for you or to do harm to you.
What happens when this organization is compelled by the TLA to give up the lucky charms, and there is no team of attorneys to fight back, and no billions at stake, and there is a gag order? And, given the rate at which a "free" SSL certificate will proliferate, these will be some valuable lucky charms.
This is not FUD. This is simply recognizing that "free" SSL certificates don't really address the issues that arise from centralized authority in a decentralized economy.
Let's Encrypt is the effort of a benefit corp (ISRG) run by people who care about security and privacy enough to bake it into the foundations of the organization [1]. I think this makes them more trustworthy than for-profit CA's, which have a history of misunderstanding the fundamental roles they play in the security chain, e.g. [2].
1. https://en.wikipedia.org/wiki/Internet_Security_Research_Gro...
2. http://www.computerworld.com/article/2501291/internet/trustw...
Lavabit waa ordered to give up their private key, despite the fact that Lavabit wasn't, itself, under investigation. In other words, they were forced to give up their clients privacy and were given a gag orders.
Attorneys don't exempt anyone from anything, but your comment seems to suggest their existence is for entertainment. A team of attorneys might have found a way out of the mess for Lavabit.
The main thing that you trust (every) CA to do is to not issue a certificate for your domain to somebody else.
Which 99% of people already do when the buy a domain name.
There is NO evidence that using SSL restricts your freedom of speech. There is evidence to the contrary though, where SSL allowed people to speak freely without having their communications intercepted or monitored.
Certificate Authorities only reject websites for certificates in rare cases where the domain bears resemblance to a well known company (such as "paaypal.com" or "microsoftproducts.com"). This is not something that every CA does not something that a CA HAS to do.
There is no "false" sense of security HTTPS IS encrypted, and CA signed certificates ARE authenticated. Claims that the whole CA system is MiTM by government are largely unsupported, and if you believe that, then you are screwed over HTTP anyway.
I dont disagree that there are some disadvantages to an HTTPS-only web, but those generalizations are wrong.
How so? Do you expect browsers to stop serving content from sites using boring old HTTP? And the fact is that we've had to go through a central authority to put a website up for a long time, with DNS.
Just look at the stupid way browsers treat self-signed certificates: these are strictly better than plaintext, but plaintext gets no warning and self-signed certificates are warned about and in some cases actually blocked.
Similarly, one mailer (exim, I think?) on seeing an untrusted certificate would actually downgrade to plaintext. There aren't enough palms or enough faces for that.
Let's Encrypt users (in almost every respect) are not more exposed to risks of Let's Encrypt misissuing certificates. (They are more exposed to risks of Let's Encrypt wrongly revoking a certificate, but that creates an availability risk rather than an integrity or confidentiality risk.) In particular, Let's Encrypt never has access to your server's private key or to your TLS session keys. There is no way that Let's Encrypt could take a recorded TLS session and tell somebody how to decrypt it; what we have are signing keys, and all that they ever do is sign things (normally claims about other keys that could be used for other purposes).
Although Let's Encrypt, like any CA, could issue an additional fake certificate which someone who controls your network could use to impersonate you, any site is already exposed to this risk from every CA, whether or not the site uses Let's Encrypt. Let's Encrypt could issue a fake certificate in the name of a site that uses StartSSL or Verisign -- or Verisign or StartSSL could issue a fake certificate in the name of a site that uses Let's Encrypt.
As I've said a number of times in a number of contexts, the people working on the Let's Encrypt project don't think that this model is perfect, and many of us have been involved in expressing concerns about CAs' power in the past. As a result, we're working to limit Let's Encrypt's own power to misissue certificates by participating in the Certificate Transparency system, and hopefully by adopting and encouraging our users to adopt other technologies that will protect them against misbehavior by CAs, including us.
We encourage our users (and non-users) to adopt technologies that would reduce the need to trust us, including HPKP, which lets sites themselves make assertions about what keys they'll use, which browsers will then enforce even if CAs say something different, and Certificate Transparency, which lets people confirm that certificates they encounter in the wild have been publicly disclosed worldwide by the CA that issued them.
If you have other ideas for how CAs can be made less trusted, more transparent, and more accountable, we would love to hear them! And let me express my appreciation for the people who have been working to create the means that we have to do this today.
(If you're not a Let's Encrypt user and want to protect visitors to your site against risk of misissuance of a certificate by Let's Encrypt -- or any other CA! -- you can also adopt CAA and HPKP, to give visitors a browser-side way to enforce your intentions about what certificates they should be accepting.)
I'll also note that ISRG is publishing legal transparency reports, something which is still not very common in the CA industry.
https://letsencrypt.org/documents/ISRG-Legal-Transparency-Re...
