Item — HN Reader

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.

10 comments

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.

Fair enough, that makes sense.

I understand that there are about 17k certs with paypal.com in the name. Are there plans to try to prevent some of that in the future?

"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].

[1]: https://letsencrypt.org/2015/10/29/phishing-and-malware.html

[2]: https://groups.google.com/forum/#!msg/mozilla.dev.security.p...

[3]: https://groups.google.com/forum/#!msg/mozilla.dev.security.p...

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.

doesn't the gray padlock currently mean the site isn't 100% secure? Meaning the page itself is but an asset isn't?

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.

I believe that's a padlock with a strike through. Possibly grey or yellow, I'm not sure.

This is how it looks in latest chrome: http://imgur.com/a/3R48U

No, why should there be? If you own a domain name you can get a DV cert for that domain name. It's that simple.

There shouldn't be any policing at all of which domain names are allowed to have certificates.

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).

[1] https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.htm...

> 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.

> CAs in practice don't verify who you are; they just verify that you are the entity that controls a particular domain name.

Strangely, our CA called our human resource department to verify a lot of the information. I guess its all in who you chose.

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.

Doesn't IE (or Edge?) show a big green bar if it's one of the highly verified certificates?

I think all the browsers do. I the UI had the name of the organization too.

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.

For your own projects, nothing.

For me accessing your project, third party validation that a consistent entity exists is worth something.

Accepting any self-signed cert that gets presented is the same as not using certs in the first place. Just use http://.

If you pre-share or pin self-signed certs that can be useful but in a different use case.

Come on, it's not literally the same. It at least requires an active attacker to read your data, whereas HTTP can be read passively.

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.