Serious question. What does LetsEncrypt buy me that I could not get from having a knob in applications and browsers that lets me accept self signed certs?
To be clear, the reason I am asking is that historically a CA was intended to be a way to validate "who" you are talking to. LetsEncrypt is providing a signed cert that does not validate an entity. It just solves the self signed cert, which could also be solved in applications by having a setting to "Accept Self Signed Certs". Some apps and appliances already have this.
If you ask LetsEncrypt for a certificate for www.google.com you won't be able to get it as you cannot solve the challenge LetsEncrypt issues to check that you actually own www.google.com. Creating a self-signed certificate for www.google.com on the other hand is something everyone can do.
"paypal.com in the name" is a bit too ambiguous. You can register a subdomain like "paypal.com.example.com" and acquire a certificate for that, that's correct. There have been no mis-issuances under the actual domain "paypal.com", to my knowledge.
Here's a blog post explaining why Let's Encrypt does not think it should be the CA's job to prevent this[1]. At least two browser vendors seem to share this sentiment[2][3].
Hopefully not. Domain name similarity does not fall within the scope of DV certs.
For the usability problem you're hinting at, people mistaking DV certs for EV certs, I believe web browsers should consider demoting the color of the pad lock displayed for DV certs from green to plain text color, while still retaining the pad lock symbol (plain http would still be red). This solution would both provide enough distinction between the two types of certs to the normal enduser without retraining them; "look for the green padlock" would still hold.
That said, 17k (even multiples of this) is still a rounding error compared to the total number of certs issued. I believe the public good done here far outweighs the bad.
I always disable mixed content so I honestly wouldn't know browsers indicate mixed content. I was under the impression that yellow was used. Apologies for the confusion.
My point in my previous comment was that browsers should consider exposing the distinction between EV and DV certs to the user in a way that doesn't break their mental model of how browsers indicate the security of websites. How this is implemented is probably better handled by others more knowledgeable in UI design than I.
Safari (at least on the Mac) shows EV certificates with a green padlock and the organization name, which I think makes it nicely clear. PayPal shows up as "<green padlock> PayPal, Inc. www.paypal.com" whereas a scam site will just show "<gray padlock> paypal.com.scammers-r-us.com."
Teaching people to look for this might be hard, though.
Organisation names are not, to people's surprise, globally unique. I don't have a Mac but a common "solution" there is to add a country flag, so an Australian firm named Top Burgers gets a different flag icon from an Irish firm by the same name.
But wait, is the burger place you like the Irish one or the Australian one? The faux German decor and the American accent of their spokespeople on TV give no hint. Turns out - neither, the Top Burgers you love are legally named Upper Deck Barbecue and Burger Company, Inc., and so their EV would need that mouthful on it.
So yeah, EV isn't worthless, but it's probably not going to fix anything much you'd actually care about. If I ran a business with PayPal's money I'd get an EV cert because the price is a rounding error. But for 99.99% that's money they could spend on security or customer service improvements that'd see an actual return.
It'll be way harder to get an EV certificate for "Paypal Inc." than to get a DV certificate for paypal.com.scammers-r-us.com. Getting two legitimate companies mixed up is a problem, but far less of one than getting a legitimate company mixed up with a scammer.
I would agree that it would not be scalable or fair to LetsEncrypt to police all of them. Would it be feasible to maybe just police the top 50 or top 100 financial institutions?
All public CAs are obliged (by the Baseline Requirements agreed with Mozilla, Apple, Microsoft etc.) to operate a "high risk" list of names for which they will do additional manual checks. For Let's Encrypt the effect of requiring "manual checks" is that you can't get a certificate because they only do automatic issuances.
However the BRs deliberately don't say what should or should not be on the list. Is Gmail as important as a Russian bank? Probably not if you're Russian!
Also of course CAs are not exactly rushing to reveal everything on their lists, for much the same reason you don't get told every security measure in place at your local bank.
Finally, bad guys will react to any such restriction, if they can't get paypal.example they'll try paypa1.example, not allowed that? How about paypa1-web.example? Even the rules LE have in place today cause problems for somebody a few times per month because their South American trucking business has the same initials as a German bank or whatever.
Why do we constantly hear that Lets Encrypt need to police this but it hasn't been an issue in years of commercial CAs doing exactly the same thing?
I ran phishing susceptibility tests for years before LE and would often just expense a $9 certificate for something similar to paypal.com and never had an issue. In fact any time it came up, I got a sales pitch about "this is why you should pay for an OV cert".
CAs in practice don't verify who you are; they just verify that you are the entity that controls a particular domain name.
LetsEncrypt does this automatically, for free, and in a more user-friendly way. For information on the security considerations involved, see [1]. These are similar considerations to those of most DNS-based CA verification methods (which is most of them).
> CAs in practice don't verify who you are; they just verify that you are the entity that controls a particular domain name.
They do that at a minimum. OV and EV certs require more work and do verify who you are (for some definition of "who") and that's where the more expensive CA's add value.
How do we make it more obvious to non technical people the difference between a DV cert and other certs, in a way they will completely understand?
I understand what the browsers do today and I don't believe this help protect people. It should be very clear what type of transport security is in use, along with a score and what type of identity has been verified and what that means. I honestly don't know the answer to this, but I do know the existing methods in browsers just doesn't give a clear picture to non technical people.
It's not about the CA, it's about the level of validation your chose. All major CAs offer all three levels of validation - DV, OV, EV. DV doesn't involve any verification of personal/company details, no matter the CA.
You don't get to say "all major CAs" referring to everybody else now, Let's Encrypt is definitely a major CA too now :-)
Also some (maybe you don't think they're major?) don't offer DV. After all they can't be cheapest or fastest so why not focus on a product with higher value.
LetsEncrypt verifies that the server making the request controls the domain against which the certificate is issued. Their certificates are most definitely not self-signed.
Anyone can generate a self-signed cert for any domain, LetsEncrypt only allows somebody who can demonstrate some level of control over the content in that domain.
Here's a concrete scenario: You host linuxbender.com and use a self-signed cert. You set your browser to trust self-signed certs. When you connect to your browser to linuxbender.com, I MITM you. I serve you a _different_ self-signed cert, which you then trust. I can read your traffic.
In this scenario, if the site was secured with LetsEncrypt, you wouldn't have to trust self-signed certs, and I wouldn't be able to MITM you.
Key-Pinning goes some way to combating this issue too, but doesn't solve every case.
In addition to what the other replies have already said: Domain Validated certificates have been a thing for years before Let's Encrypt entered the market. Most sites have used them and all mainstream CAs have automated the validation procedure and do not verify the entity requesting the certificate, only domain control/ownership.
There's different grades of validation, some of which audit your organization's legal structure to make sure you are actually a legitimate company. Let's Encrypt does domain validation, which validates that the entity it is issuing a certificate for has control of the domain name.
In practice, I doubt most people that use web browsers actually know the difference. They just see a green lock and assume everything is good to go.
I think that you are over-estimating just how much "validation" was done for a cert under the old model. A LE cert, like most standard CA certs just verifies control of the domain in question at some point in the recent past. A self-signed cert does not even rise to that level and making self-signed certs anything more than an oddball testing tool invites easy MITM.
You're right. It's not literally the same. However, it is effectively identical.
It is absolutely trivial for even a 5 year old to click a button and perform a downgrade attack on this type of an https:// connection. That is why accepting any self-signed certificates should be treated identically to http:// connections.
The issue is that if there is something like that, it has to be on by default. Otherwise, there's no difference between that and using self-signed certs now.
To be clear, the reason I am asking is that historically a CA was intended to be a way to validate "who" you are talking to. LetsEncrypt is providing a signed cert that does not validate an entity. It just solves the self signed cert, which could also be solved in applications by having a setting to "Accept Self Signed Certs". Some apps and appliances already have this.