Being told that you now trust someone with your secrets via a news website is a pleasingly succinct display of everything that's wrong with the CA model.
Well. The CA model is community trust. I am told all the time, often by news websites, that my government now trusts or distrusts some other government, that my employer now trusts or distrusts or is even part of some other company, etc. I don't know if I personally think that the embargoes on Cuba should be lifted, or my company's new vice president is qualified for the role, or (if I worked for VMware) Dell is a good employer, or my savings should now be held by Bank of America, or whatever. But that's how living and working in a community works.
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.
CAs are CAs because they established themself. Personally I don't trust them because they are susceptible to MitM attacks & government intervention attacks.
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.
We’re pleased to announce that we’ve received cross-signatures from IdenTrust
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.
I don't think he was saying they acted poorly by announcing on HN, but that he would prefer to grant someone trust rather than have it forced on him before he even knew about it. Not an easy task for a functional web, but it would obviously be better if possible.
There's many ways, all obnoxiously complex unless you go back to a CA-ish voluntary trust model.
Keys as addresses (I2P, Tor hidden services, CJDNS) fixes a large part of the security problem, then on top of that you can add your choice of address translation. WoT style individualized trust webs? Trusted lists of name assignments DNS style? First-come first-serve á la Namecoin?
Not necessarily. You could also place ___domain validated trust in the registrars, to cryptographically verify their delegations. That would build a chain of trust which you in turn could use to validate keys for services in those domains.
That's the DNSSEC+DANE approach and that's still the same as the DNS approach I listed (trusted name registry lists), except that the address isn't an IP-address (or in other words, your ___domain's DNS server that says what IP addresses your subdomains have is itself identified by a public key).
Your last three sentences are sarcastic nerd-rage (with which I completely agree), but your boss (not _your_ boss, necessarily, but the more generic/stereotypical "your boss") utters those words in complete earnestness...
To be clear, I am massively excited to use Let's Encrypt and plan on setting up SSL for the first time ever when it launches. I am legit broke so I can't afford to pay a lot of money for someone to have an automated process of:
gpg --gen-key
I was responding to parent, that announcing trust is a werid quirk of the CA model. TBH, that is correct, but I find it more bizarre Let's Encrypt has to be "trusted" by an unknown company that no one really knows anything about. That is the bit I find weirdest.
Although I loved your sarcastic remarks about the cool pictures, I do want to point out that there are two issues with your argument:
a) There is something else that you know about IdenTrust, and that is that your browser vendor trusts them. This is the whole point of this CA thing: in the end you trust whom your browser vendor trusts (with the option of removing CAs for which you disagree). This is far from perfect (especially since the vendors' vetting process can be quite opaque), but it is not nothing - after all, you should trust your browser vendor, otherwise all the encryption of the world can't save you from someone eavesdropping on your websurfing.
b) Your argument can be read (or misconstrued?) to state that it would be perfectly reasonable to trust IdenTrust if they had a 2015-looking, professional website written in Angular and node instead. Which, of course, is not the case as many who entrusted their money to fraudsters with professional looking websites will be able to attest to.
You raise some good points, and I totally agree. The thing is, when the drduh Yosemite guide came out (around the time Google dropped CNNIC) I looked into it a bit. I dropped a ton of certs, mostly international ones (about 40) and the only site that broke was Bing.
> you trust who your browser trusts
Exactly, and my OS. But I run Mac and I am sure Windows users can relate, there are over 200 CAs and I have no idea what heuristics can be used to determine whether they are trustworthy. It wouldn't be a big deal except a compromise at ANY means they could fake ANY website.
Now, on a serious note. If you were running node and you had a super clean react front end with a picture of Jamie lee Miller from hackers super imposed over the ghostbusters symbol (responsive using html5 flex boxes) for sure I would trust you with the security for every website I visit.
I just meant the comment more as idem trust looks like a random rent collector who hasn't updated their business model since 1995. As a broker of trust, I find it disconcerting I know fuck all about them and even if I did, there are hundreds more like that. If you have the money, I don't because I am broke, for sure it would be worth $100 for a padlock when a user hits your site. With nothing more to go on than their site though, it looks like they have been on autopilot for 10 years and I can't wait for Lets encrypt to go live.
An encrypted communication channel specifically doesn’t say that you trust the person at the other end with your secrets. It means that you both agree that the secrets being transferred are safe from 3rd parties.
It might not say that you trust what the person at the other end does but it does indicate that a third-party has vetted the identity of the person at the other end. Do you trust Google? Probably not with everything but you do trust that the certificate that was issued to them proves that they're at the other end of your search bar.
You would like to buy a knitted scarf from a yak herder in Ecuador. How do you propose that establish trust between you and the yak guy without an intermediary?
Crypto currency with escrow, receipt of goods validated by a robot camera sending a picture to an anonymous network of validators who say "yep that's the scarf they ordered, trigger the payment"
The commenter above implicitly rejected intermediaries. To me it is clear that my browser is a trusted intermediary, and part of my trust in them extends to letting them decide whether to trust IdenTrust. And part of my browser's trust in IdenTrust extends to letting them decide whether to trust Let's Encrypt.
In the yak-herding analogy, Let's Encrypt is a new charity in Ecuador that provides market services for scarf knitters. IdenTrust is a large regional trader in South America. My browser is the local yak-scarf store down the street. It seems totally obvious to me that, in this case, of course I'd hear about IdenScarf making deals with Let's Shave Yaks on the news. But the parent commenter is unhappy about the local yak store not being directly involved, and thinks it's some form of failure of the global yak-scarf supply chain that an individual consumer isn't part of that conversation.
New wannabe CA Entity B can approach an established CA entity A, convince A to sign B's root or intermediate cert, and then B can forge browser-trusted certs for every SSL website on the net that's not pinned.
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.
How is this any worse than trusting the original CA? There's almost assuredly some high standard they use to cross sign, and they'd get revoked if they do that incorrectly. You're failing to note that MCS was revoked as was CNNIC. So, boom, 2 bad/laughably incompetent players are out.
Trusting a CA means trusting them to write certs, even via an intermediary. If you don't actually trust them, remove those CAs.
The CA model has lots of problems, but I don't see what additional harm this actually causes.
Because it doesn't settle with having as many single points of failure as the number of CA entries in your root CA list, they are getting multiplied over and over.
Is it (technically) possible to limit CAs validity to certain subset of.. something? I.e. certain CAs could only be used to verify limited number of.. domains? something?
If you're talking about limiting to certain TLDs, like American CAs not being able to issue .ca or .in or .paris, there is a spec for that, called name constraints. It is intermittently supported, and there was a thread on mozilla.dev.security.policy, primarily focusing on government CAs, which argued that doing such a thing fractures the open/egalitarian nature of the internet, by making zones where security is less important:
I can imagine other ways you would restrict certificates (for instance, I'd kinda like to see a spec for a "half-CA", where you need two half-CAs under distinct organizational control to sign you), but I don't think anyone has specified the problem for those precisely, let alone proposed a solution.
Yes using "Name Constraints" but that RFC / extension is really broken, and implementations don't support it. See 4.2.1.10 of https://tools.ietf.org/html/rfc5280.
That's how SPKI (RFCs 2692 & 2693) worked: one only trusted an authority for certain things. This would work very well for DNS names and IP addresses alike, since both are allocated hierarchically; with SPKI one could guarantee that one is talking to one of the parties who is allowed to use a name or an address.
Sadly, SPKI more-or-less died on the vine: the atrocious XPKI 'system' won by default. One of my rainy-day projects is to try to revive it: if the last 15 years have taught us anything, it's that centralised global trust is insane.
AFAIK, no it's not. However, this is the solution as far as I see it. When you buy a ___domain name from a registrar they should give you a mini-CA that's valid for just that ___domain for as long as the ___domain is registered. Then it's up to you to create and sign any certs for any subdomains. This would cut out the CA businesses entirely, enabled security-by-default, and simplify the whole system.
Allowing multisignature models would at least drop the single point of failures, by being able to require verification from multiple CAs. In combination with certificate transparency and DNSSEC+DANE it would add much stronger security.
I think the criticism was meant as one of the CA model, not Let's encrypt specifically - you have no choice about using CAs if you want to use https to serve a site to normal users. Also, I'm not the OP and think Let's Encrypt specifically is a great idea, already on the waiting list.
I was unable to connect using a vendor-specific browser on an old Android 4 device. Is this a limitation of the LE cert, or a cipher suite issue with older browsers, or something else?
Really looking forward to spreading HTTPS far and wide.
Taking a guess from the SSL Labs report[1], that site appears to be using the modern config from Mozilla's toolkit[2], which limits it to browsers from the last few years.
Let's Encrypt's DV certs will be validated the same way that any other CA's DV certs are, so im not sure why this should be the "one place" where its adopted.
I thought only EV certs (where you have to turn in some sort of financial and other types of documents to prove you're a real institution) were granted that info in certs. And EV certs are the only certs that turn most browser's address bars green.
It seems odd to me that the intermediates were cross signed instead of the having the root be cross signed.
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.
This was a performance decision. Cross-signing the root instead of the intermediate would mean that web servers would have to include both the root and the intermediate in the chain they serve, rather than just the intermediate. That would add a full packet to each handshake.
In case the main intermediate cert has been compromised and must be revoked, the alternative intermediate cert is already signed and can be used immediately for desaster recovery.
Can anyone who knows more than me say - is this the beginning of the end of the SSL cert selling business? Is there still value to buying an expensive cert from another vendor?
* 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.
Although i agree that their user interface isn't that much user friendly, it took me just a couple of hours to learn how the process is handled at StartSSL.
You let them create a certificate you then use for your login process. Then you validate your ___domain by email and then you're pretty much valid to pump out as much certificates as you want.
Only drawback is that the certificates are only valid for one year.
> it took me just a couple of hours
> to learn how the process is handled at StartSSL.
Well, if something takes 'just a couple of hours' to learn i'll happily fork over some money to ease the pain. You can get certificates for $10/year nowadays.
FYI, StartSSL's free personal SSL certificate only valid for new users for the first year, requires a valid U.S. physical non-commercial address for registration and is subject to $79 for revocation fee. Oh, it's definitely not automated, someone would have to email you back and force a couple times to complete the provision process.
I wouldn't bother with StartSSL with that many catches and hassles.
How do I know? I've got two of them in the past in two occasions.
> FYI, StartSSL's free personal SSL certificate only valid for new users for the first year
They only allow one-year certs to be generated, but you can renew them and get as many of them as you want. I've got class one certs from them for two different domains, and I've replaced both those certs twice as they've expired.
Then again, maybe they've changed their policies in the past six months.
> requires a valid U.S. physical non-commercial address for registration
Does it? I'm based in Ireland, and I haven't had to provide the with a valid US physical address, unless this is something new that they've brought in during the last half a year or so.
> and is subject to $79 for revocation fee.
Yup, that's the most annoying thing about dealing with them.
> Oh, it's definitely not automated, someone would have to email you back and force a couple times to complete the provision process.
I can't say I've had that issue myself. They're not as fast as I'd like, but I've never had any major problems with them.
What would be the difference in using WoSign vs any other? If you use a CSR and not let them generate the private key I would think their certificates are identical to any other providers.
It doesn't matter much for TLS certificates (the slowness might though) except if they choose to issue another certificate under your name with their private key to MITM your connections, it'd look more legitimate if your real certificate is issued by the same CA, but admittedly, the real issue here is on the client side: browsers trusting way too many CAs that directly include many governments.
In addition to the other differences, as far as I know letsencrypt is the first to offer free and automated certs. None of the other ones offer an API, do they?
One of them is not like the other, and that's CloudFlare's free SSL, which is more like "half-SSL". You only get free encryption between Cloudflare and the user, but not between your site and Cloudflare.
Unfortunately, this means you either have to use a self-signed cert which CloudFlare will not verify at all (meaning it can be MITMed) or use one signed by a trusted CA... which brings you back to square one.
There is still an advantage here, though: You can use a different hostname on the origin server.
Use this to serve e.g. an S3 site on your own ___domain using SSL: S3 -> CloudFlare (with CloudFront) uses Amazon's certificates for their hostnames. Cloudflare -> internet uses your website's hostname and certificates.
> self-signed cert which CloudFlare will not verify at all.
Why would they do that? I never used this feature of CloudFlare, but it would be only logical to require you to upload the cert so they can verify against it in the future.
In which case, it can be easily MITM'd by an attacker sitting between CloudFlare and your server, which makes it only slightly better than plain HTTP. It would have been great if CloudFlare let the user to upload and pin a specific self-signed certificate that it could then validate to prevent such attacks.
I think there was some rumors that they are - or are planing - to offer certificates signed by a private Cloudflare CA exactly for the purpose of encrypting the traffic to the backend.
Not yet, because Let's Encrypt doesn't provide wildcard certificates as of now. This may change in the near future, though.
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.
An argument can be made that Let's Encrypt doesn't need wildcard certificates since new certs can be generated automatically every time a subdomain is added.
An interesting usecase of wildcard certs: when I do not want to publish the hostnames I am using. Sandstorm[1] uses unpredictable hostnames as one mitigation against various cross-origin attacks -- if the attacker doesn't know the ___domain of the app, he can't try to use XSRF against it[2].
If you are willing to only accept SNI enabled clients (the vast majority nowadays), you can achieve the same by having one cert issued per subdomain, then configuring the web server/reverse proxy to use them.
There are a few existing Nginx configs for that (search for "nginx dynamic ssl cert").
I think there are other problems for doing this for Sandstorm. One is the delay when starting to use a new hostname (right now Let's Encrypt might take around 20 seconds to issue a new hostname, which may well increase to the originally-predicted one minute eventually), while another is that all Let's Encrypt certificates are published, so if you really want the hostname to be completely unknown to an attacker, the individual Let's Encrypt certs wouldn't work.
Anyway, Sandstorm developers told me that they wouldn't plan on using Let's Encrypt while it doesn't offer wildcards, so I think we are missing out on supporting this use case.
It would be relatively easy to write a simple bash script to automate it. Granted, it might take a bit of time to generate a few thousand certs, but it wouldn't take more than a day if you only have a thousand or so.
It's not just creating the certs that is the challenge but also managing them; back-up, revocation, re-testing after expiry and across different development environments etc
And from the client perspective is makes pinning much easier.
I'm not a fan of one-wildcard-to-rule-them either but keeping active certs to a handful through the judicious use of wildcards is a real boon.
If you use the Cloudflare style delegation of SSL authentication signing to a trusted auth server, it can be simplified. The individual servers only holds the public cert and a private internal secret, one server holds your certificate private keys.
That server would be used to keep track of your domains and certificate status and which servers are authorized to work with which domains, etc... Also easier to backup.
The best part is, the cert you use to log in to your account itself expires after a year. So if you don't renew it in time you lose the ability to log in and issue a new certificate for your site, right at around the time your site's certificate expires.
They specifically tell you that you need to back up your login-cert or you will lose access.
One year passed, and I checked my backups. Yup, there it was.
If you take security seriously, you should actually read what's on the page instead of clicking "next, next, next" like some driveby malware-installing Windows-installer. And then this shouldn't be an issue.
I guess this is StartSSL's way of not having to deal with people who don't take security as seriously as they do.
The rest of the connected world has determined that username and password, supplemented by OTP methods or some other multifactor authentication, is enough.
Having a login cert is fine if the "user" is an organisation. It is a broken model for individuals or small businesses.
Well, Let's Encrypt models is based on automated confirmation of ___domain ownership (or to be more accurate, control rather than ownership). Automated software proves that the entity who is asking for a cert for a.example.com really does have control over a.example.com, because they were able to make a change on the host that a.example.com refers to. And based on this, issues the cert to the entity.
This level of proof of control is standard for DV certs, although other providers haven't automated it to the extent Let's Encrypt has, at least not with as high-quality software. One hole in this verification of course, is that 'control' may not actually be 'ownership', it could be someone who's hacked the host or DNS. But that's not unique to Let's Encrypt, it's a side issue, proof of control is standard and accepted for verification for DV certs.
So anyway, that kind of automated proof of control is a lot harder to apply to all of *.example.com, not just an individual host a.example.com. There are likely ways to do it well, but it's harder to do and harder to get right. Is probably why Let's Encrypt, at least for now, is not doing it.
Wouldn't they just need to verify control of the ___domain, instead of a single host on the ___domain? If I control example.com, it's fair to believe I can control all hosts on the ___domain.
How do you verify control of a ___domain? Their current mechanisms verify control of a _host_ pointed to by a hostname, not of a ___domain. They'd need different mechanisms to verify control of a ___domain.
If you control the ___domain `example.com`, sure. if you just control the single host that `example.com` points to, that doesn't neccesarily mean you control the ___domain, and in fact DNS contortions are needed to even have example.com point to a host.
You could verify ownership of the DNS config for the ___domain. It's not all that uncommon to verify ownership of a ___domain for various services by sticking something in a TXT record on that ___domain (or on a specially-named subdomain). LetsEncrypt could do something similar to verify top-level ownership. After all, if I have control over the DNS zone, then I trivially have control of any host on the ___domain too (just point the DNS at my own server).
Another benefit of this is ownership can be validated on an ongoing basis (is the TXT record still there? yup, still valid) without requiring any software to be running on any hosts at that ___domain. And you can validate a ___domain without even having an A record if you want (say, if you're getting all your ducks in a row before exposing your server to the world).
I used to use them. You have to set up an account with a client certificate, which is a pain, then be manually approved. The free certs are for personal use only so they will deny you if they think you will be using it for business of any sort.
Let's Encrypt is also limited in that it issues Domain Validated certificates only. They aren't planning on issuing EV certificates (the "green address bar").
In addition to using & verifying the legally registered name, it must be verified that there is a physical address for the business, if that address doesn't match the registered ___location, additional verification is required. There are additional provisions of verification as well. See section 11 of the same document.
Obviously the Citi example was a joke, but most actual certificates I see are to "R L Media Enterprises" or whatever the D&B name of the business is, which is opaque to me anyways.
EV certs are expensive because they have people in the loop, and so getting a cert for an obviously misleading name should be much harder. You'd have to pass an eyeballed sanity check.
EV certs are a total waste of money. Pretty much everyone except maybe the site administrator won't notice and won't consider it a problem when a lock icon is shown instead of a green bar.
> Pretty much everyone except maybe the site administrator won't notice and won't consider it a problem when a lock icon is shown instead of a green bar.
I don't know if it's worth the money per se, but you can pin a couple of trusted CA root EV certs via HPKP and know it's much more difficult for someone to "accidentally" issue a valid cert for your site.
If you do that, users won't see a lock instead of a green bar, they'll be blocked from accessing the site at all (if it's not their first visit and they're using a modern browser).
You can pin any certs via HPKP, including self-signed ones.
The only security feature EV certs have over regular ones right now is the use of certificate transparency, but that should be extended to non-EV certs within 1-2 years.
No, the security feature is that if you only pin, say, Verisign EV root and Digicert EV root then an attacker would have to pass EV validation at those vendors. Which is much more difficult to do than to get any cert anywhere.
You could pin your own cert, but that makes it difficult to rotate keys in a heartbleed type situation.
Though it would not protect from factoring because most EV roots are the same key length/hash.
For anyone else reading, this works because the root programs give authority to issue EV certs separately from other certs. To keep the authority separate (most, perhaps all) CAs use separate roots for EVs.
> Is there still value to buying an expensive cert from another vendor?
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 run https://certsimple.com. We only do EV certificates, and we do it much faster than any of the existing companies, which normally quote 7-10 days to complete the validation process. I waited around a month for GoDaddy earlier this year, which is how I ended up making CertSimple.
CertSimple do EV certificates in an average of 5 hours.
- We check the customers info against the required government information sources (as well as a number of other places) before customers pay us.
- After we take the order, we provide a specific set of instructions based on a number of characteristics of the customer's actual business to make the validation process as fast as possible.
- We have a real focus on UX: there's no software to install or command line questions, our validation UI updates live, and we manually follow up with every customer to iterate our product.
Dis you hear about the CIA AOL mail box hacked ? Watch out for "social" intelligence. Other people could get the info you are checking and pretending to be the company.
They are generally good. There was one case when they started pulling a Comodo thing on us - the lawyer's signature was unintelligible, go and redo the paper - for some secondary document. But each email includes a note to email their support head if something's off, which is what we did and he had the cert issued in an hour after that. So the tops do care about their service levels and there's an easy way to escalate issues.
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.)
Yes, there are now several options to manually attain the certificate.
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.
Serious question, to what degree is one defined as being independent? When you have "platinum" sponsors like akamai and cisco, and can take donations through paypal?
They are a separate legal entity, with multiple independent sources of funding and a diverse range of board members[1]. I'm not sure about degrees of independence, but I would say this satisfies my criteria. Are you arguing they aren't really independent of their sponsors?
But I will say that, without any numbers, its hard for me to say either way. Clearly, RSA was in independent legal entity, but a $x million dollar check didn't stop them from peddling shoddy crypto… though that's not something surprising to hear in this community.
It means certs signed by Let's Encrypt will work just fine for people without any special setup. See https://helloworld.letsencrypt.org/ for an example.
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.
can you sign a cert for SSH? I know that you can add the SSH server public key fingerprint as a DNS record and sign an openSSH certificate with your own private CA but are there any public CAs who will sign SSH certs and would the ssh client even trust anything other than a manually added CA?
Yeah - [Open]SSH supports signing for host and user keys, and you can operate your own CA, and the certificates you issue can encode a signed set of permissions/access controls with them (E.g permit-agent-forwarding, permit-X11-forwarding, certificate life times) this functionality is IMHO vastly underutilised.
OpenSSH certificates are not X509 certificates though, and out of the box SSH servers will not trust any public authority.
Also, AFAIK CA cross-signing, intermediates and other things that are fairly commonplace in X509 land are either not supported or not widely supported in OpenSSH.
Using the OpenSSH Certificate format, many of the common features from X.509, like intermediates, cross signing, key usage attributes or restricting access based on an attribute in the certificate are not part of the spec:
When I first learned about OpenSSH Certskeys, I was really excited; Spent awhile trying to make it useful, but you end up building all the CA infrastructure, and this time instead of distributing certificates to servers once a year, you want to distribute certificates to your _users_ every month or two -- so the pain is higher, there is less automation, and everyone on your team feels it....
Exploring OpenSSH certs is what led me to founding ScaleFT. There had to be a better way.
ScaleFT Access leverages these SSH Certificates, but we expire them every 5 minutes to provide other features that are hard with the limited capabilities of the format:
There are patches to make OpenSSH use X.509, but they are not widely adopted... and asking people to patch a sshd is a non-starter for many environments.
There's a pretty old (but apparently updated) patch-set for using x509 certificates with openssh. I realize commenter above made a typo, but it might be of interest in this thread:
You could, but SSH is used for actual security, and adding the variable of a third party makes that situation strictly worse. SSH keys are meant to be distributed through some side channel.
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.
IdenTrust is an interesting organization. IdenTrust is a bank consortium acting as a public key certificate authority and secure applications provider whose members include over 60 of the largest banks in the world. John Sculley has been IdenTrust's chairman since 2006.
Are they planning on not relying on a 3rd party root CA and instead, ask all browsers and OS vendors to include LetsEncrypt CA? IOW, is this [trusting IdenTrust] a first step, or is this the original goal?
This is a temporary step. There are two versions of their intermediate cert, the one in this article that is cross-signed and another that is signed by their own root (which isn't yet included everywhere). There's a diagram on this page that explains the situation: https://letsencrypt.org/certificates/
Instead of 3rd party CA, wouldn't it be more secure if the browser will send a hash of website's public key to a few trusted websites and have them verified the public key is valid?
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?
Remember that you only need one of the hundreds of CAs (650 at my last count) to generate you a cert to essentially compromise a site's connection security. Free certs mean more sites will use TLS, which means there will be more targets, which means more incentive to start attacking the weakest CAs and/or their verification practices.
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.
Thanks to HTTP Public Key Pinning (HPKP), this is no longer a threat:
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 don't get to say there is no threat if almost every website today is vulnerable.
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.
You don't get to say there is no threat if almost every website today is vulnerable.
I didn't mean that literally the threat has been eliminated due to HPKP; it's yet another tool that can be used.
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.
HPKP isn't software--just additional HTTP headers that pretty much every web server can be configured to send.
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.
Key pinning is a trust-on-first-use (TOFU) mechanism. The first time a UA connects to a host, it lacks the information necessary to perform Pin Validation; UAs can only apply their normal cryptographic identity validation. (In this document, it is assumed that UAs apply X.509 certificate chain validation in accord with [RFC5280].)
It isn't foolproof, user installed Root CAs or roots installed by 3rd party applications are given permission to override pins. So HPKP wouldn't protect against scenarios like Superfish.
This is something we entirely plan on doing, in fact we currently submit all issued certificates to a number of CT logs (which can be viewed here https://crt.sh/?Identity=%25&iCAID=7395).
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.
Is there an easy way to pull out the cert and load it into an AWS ELB without running the client on the server it will eventually protect? I'm not a big fan of using software that auto changes my config files, plus you can't actually run scripts on ELBs.
let's encrypt uses ACME protocol for certificates. You can use your own tools to handle it - either automatically or manually. Their automated client is just a user-friendly wrapper.
What does this mean to a new user? Can I now get a ssl certificate? will it be cheaper, or even free? I saw they have a beta-program for the certificate but don't know what it exactly does.
I really dislike the fact that a CA is able to bless a new CA completely independently. Does this cause anyone else the slightest amount of anxiety, or am I just being paranoid?
Whats the alternative to CA being able to delegate signing? Would you prefer having browsers constantly being updated with new lists of CA's, maybe one new per day.
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.
Yeah, I guess I think it makes more sense for the browser manufacturers to be the people to whom I delegate that responsibility. I already trust them not to run malware on my computer and to accurately display the SSL state of a connection.
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.
It seems like its an important thing to be able to express. They are extending their trust to the new CA. I believe this information is available to clients if they wanted to choose to reject cross signing.
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.
Could somebody clarify: LetsEncrypt allows anybody to create certificate for any ___domain, so would not that allow anybody to create MITM certificate for any such ___domain?
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.
If a site has tons of https links leading to it, or uses HSTS, then MITMing it without a cert would not be useful. So you MITM it with Let's Encrypt, and they will give you a cert and you just increased your attack capabilities by leveraging Let's Encrypt.
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.
That overview description lacks the security details that is in place to mitigate that specific attack. They described 3 tactics against MITM attacks in the last debconf.
#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.
> You can only obtain a certificate for a ___domain if you can validate that you control the ___domain.
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?
This is why HTTP Public Key Pinning was created as a way to tell browsers to trust only a particular certificate, not just any certificate that was signed by a CA in the browser's trust store: https://news.ycombinator.com/item?id=10418144.
Key pinning is a trust-on-first-use (TOFU) mechanism. The first time a UA connects to a host, it lacks the information necessary to perform Pin Validation; UAs can only apply their normal cryptographic identity validation. (In this document, it is assumed that UAs apply X.509 certificate chain validation in accord with [RFC5280].)
The UA will not be able to detect and thwart a MITM attacking the UA's first connection to the host. (However, the requirement that the MITM provide an X.509 certificate chain that can pass the UA's validation requirements, without error, mitigates this risk somewhat.) Worse, such a MITM can inject its own PKP header into the HTTP stream, and pin the UA to its own keys. To avoid post facto detection, the attacker would have to be in a position to intercept all future requests to the host from that UA.
Thus, key pinning as described in this document is not a perfect defense against MITM attackers capable of passing certificate chain validation procedures -- nothing short of pre-shared keys can be. However, it provides significant value by allowing host operators to limit the number of certification authorities that can vouch for the host's identity, and allows UAs to detect in-process MITM attacks after the initial communication.
I asked this question the last time LetsEncrypt came up, and got a very good answer:
M2Ys4U 35 days ago
According to their 31C3 talk, they will use multiple
connections from multiple locations (possibly including
Tor?) to mitigate against these attacks.
So they validate it fairly extensively to make sure it really is the ___domain.
As a condition of being trusted, LetsEncrypt has promised to do "___domain validation" before creating such a certificate. Domain validation is usually done by sending an email to the technical contact in the ___domain's WHOIS records.
It can also be placing a file of authentication data at a chosen resource ___location within the ___domain in question. (which is, I think, what their tool automates doing)
No, it allows site owners to create a certificate for any ___domain they can prove they own. Then, the certificate has to be installed on the server serving the site. Using it from any other server will cause browsers to reject the certificate.
Is there some web interface to sign my certificate, similar to startssl? I don't really want to run new program in my server just to generate certificate.
You could run it on a laptop to get the cert, then install on the server. But right now it remains an invite only beta until they get ready for general availability
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.
I like that statement "community trust"...much the same I have come to trust most of the wisdoms on this site. I for one-learn, and greater, I learn from each of you the value of clarity. So trust as David Abshire says, "Is the coin of the realm, the glue, the oil, (alternative energy-) ingredient."txs, dSnapAp. SFCA.
In a mobile only world where your critical business runs only via mobile app do CA based SSLs even matter? Why not use your own CA with your own certificates and don't have to trust any CA?
The next step should be to stop trusting any other CA, and have Let's Encrypt support EV certificates by working with other CAs and still requiring Let's Encrypt DV verification.
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.
But we are waiting for the client, no? If I understand correctly, the client will enable us to install Let’s Encrypt’s certificate on our web server. I assume, “general availability” is when the client will become available for everyone.
general availability means a certificate, that is accepted by all browsers, can be requested and fulfilled. Right now the closest thing we have is a waiting list + very few https servers answering with such certs.
I'm all for native desktop and mobile applications, but in this case I'd actually love a web app - enter your ___domain, get certificate.
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.
But you need to run something on the server to validate that you've got control of it on your ___domain. A web app isn't enough.
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.
Er... you're trusted by a CA that's owned by a company that resides in Austin Texas...
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.
Except that the courts are used there time and again to strong arm well meaning companies into paying millions out to fight frivolous lawsuits that run them into the ground. Exactly the kind of tactic you'd expect intelligence agencies to use to strong arm encryption companies into giving up their data.
It's not the patent trolling per se, it's the abuse of the legal system to strong arm companies into doing things they have no power to prevent that seems prevalent in that area of the country.
This will still require early stage overhead for many people switching over / 'going dark all the things'. Even though Let's Encrypt's goal is to make the process of encrypting the Transport Layer seamless, ubiquitous and non-commercial.
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...
I don't see how TLS is early stage overhead for someone runnig a private nginx server behind a CDN?
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.
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 a (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 I'm turning anything up with google.
I can't speak for them obviously, but here's a Go ACME client if you're looking for one: https://github.com/xenolf/lego - we're using it in Caddy[1] to make HTTPS the default for websites.
The backend and client are both very large, very different projects that share a small crossover (the ACME protocol) and were written by two different teams.
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.
> ....except Windows? Which also doesn't support docker.
So the actual problem you have is that you selected an operating system that has zero native support for interpreted languages, and you're mad that they didn't cater their software to you?
I use Ubuntu, but I've been a Windows software developer in the past. I don't immediately discount that platform, because I know a ton of developers run Windows.
Ahh, confusingly worded. I would expect it to say something like "if you use pip install, don't use sudo" not "don't use sudo pip install" ... the alternative to "don't use sudo pip install" is ... everything else in the world, so I sort of assumed it just meant, don't use pip in general.
> 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?
I really tried not to make it a rant. Sorry if it came off that way. Just seems like they made some unfortunate sacrifices to keep it as a python application (like Windows support).
The headline is wrong and not very clever for such a project.
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?
There is no U.S. law that compels us to "offer MITM access to every Let's Encrypt trusted network stream".
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.
I truly appreciate the hard work Let's Encrypt is doing.
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.
This is absolutely FUD, even if you don't intend it to be. By what mechanism do you suppose the TLA boogeymen could compel ISRG to give up their private keys, and how would a team of lawyers make one exempt from such mechanisms?
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].
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.
Lavabit held an encryption key that could decrypt evidence of a crime. They received a subpoena for that key. They followed what was likely any lawyer's advice to comply with the lawful subpoena (ordered by a judge, not a TLA).
You protect your secrets with your private key. That organization is only assures that this particular key belongs to your site. They don't have access to your key. Users don't need to trust anything they don't trust yet.
You state "This is not FUD" yet that's exactly what it strikes me as since making a certificate $0 instead of $19 doesn't change anything at all about "the issues that arise from centralized authority in a decentralized economy".
I don't think this distinction is especially relevant in this context. Let's Encrypt also has a brand that depends on its integrity, and if you're concerned about attempts to coerce certificate misissuance, they apply at least as strongly to for-profit entities.
It's not worse; it's just exactly the same broken model, now for no money and being pushed on everyone.
All this because a couple of theorists in the 1990s decided that security requires authenticity, despite decades of research to the contrary.
There are all kinds of ways to establish authenticity of counterparties. Entire books are written about that. There are much better ways than our current CA model. But we don't need any of them to have passively secure transport, over which we can then negotiate authenticity.
This is arranging deck chairs on the Hindenburg. It's nice that people will (once they finally get around to issuing certs "in mid-2015") be able to have zero-cost certs, but it doesn't change the fundamental broken-ness and wrong-headedness of having CAs in the first place.
Who claims that you can't have a passively secured transport without authentication? I mean, SSL/TLS itself uses DH key exchange, which can be used for that purpose.
The problem is having secured transport against active attacks as well, and without forcing the user to know anything about the site besides its ___domain.
The problem, which I've stated, is not that Let's Encrypt is doing something bad. It's that they have zero economic incentive to protect their brand when a subpoena comes for their private key. If you think this doesn't matter, I honestly recommend studying economics. I'm not being sarcastic at all. In fact, https://en.wikipedia.org/wiki/Economics_of_security, albeit short, is a great place to start.
I personally argued with the W3C TAG against an HTTPS-only web for this reason. Tim Berners Lee, who heads the TAG, ceremonially speaking, argued against it, too, but on different ground. The browser vendor 'experts' on the TAG totally dismissed any and all argument against forcing everyone to use HTTPS. They were basically told by their employers (the big browser vendors and CDNs like Akamai) to make it happen. HTTPS is a rather costly false sense of security. Now anyone who wants to setup a website, for whatever reason, has to go thru some central authority in the name of "securing the web" (LOL) but it's just another way to control free speech and what people do with the web.
>Now anyone who wants to setup a website, for whatever reason, has to go thru some central authority
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.
Oh wow. Really? You haven't done your homework then. So many ways to undermine the certificate authority model, including many famous cases, one involving the Iranian government gaining access to their citizen's "encrypted" traffic. HTTPs is about having traffic be open to powerful entities and closed off to the common criminal. It's a two tier model, not real security.
> it's just another way to control free speech and what people do with the web
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.
Thank you. Demanding TLS while insisting on keeping our broken PKI alive is saying that anonymous publishing is impossible.
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.
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.
Technically, yes. UI-wise, no. People have different expectations for https:// URLs, which would be broken if browsers simply accepted any self-signed cert.
I think there's a misconception here about the CA model.
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.)
Let me also add that there is a "team of lawyers" to help resist attempts to force ISRG to violate its policies or betray its users. It's not clear to me that all for-profit CAs would resist such attempts better than a CA founded by EFF and Mozilla and with a Stanford law professor on the board.
I'll also note that ISRG is publishing legal transparency reports, something which is still not very common in the CA industry.
