3 ms·

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

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.

sgift 9y ago
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.
- LinuxBender 9y ago
  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?
  - pfg 9y ago
    "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 https://letsencrypt.org/2015/10/29/phishing-and-malware.html [2]: https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/4Xy1Q6PHA7Y/-OcrrsTqCAAJ https://groups.google.com/forum/#!msg/mozilla.dev.security.p... [3]: https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/vMrncPi3tx8/M-U5F8K7AQAJ https://groups.google.com/forum/#!msg/mozilla.dev.security.p...
  - temprature 9y ago
    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.
    - LinuxBender 9y ago
      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?
      - tialaramex 9y ago
        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.
  - goodplay 9y ago
    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.
    - dawnerd 9y ago
      doesn't the gray padlock currently mean the site isn't 100% secure? Meaning the page itself is but an asset isn't?
      - goodplay 9y ago
        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.
        mikeash 9y ago
        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.
        tialaramex 9y ago
  - technion 9y ago
    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".
steve_taylor 9y ago
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.
0xTJ 9y ago
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.
kyledrake 9y ago
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.
- copperx 9y ago
  Doesn't IE (or Edge?) show a big green bar if it's one of the highly verified certificates?
  - paulddraper 9y ago
    I think all the browsers do. I the UI had the name of the organization too.
evgen 9y ago
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.
deleted 9y ago
[deleted]
advisedwang 9y ago
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.
azernik 9y ago
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.html#rfc.section.10 https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.htm...
- protomyth 9y ago
  > 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.
  - pfg 9y ago
    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.
    - tialaramex 9y ago
      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.
- paulddraper 9y ago
  > 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.
- 9y ago
pfg 9y ago
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.
Spooky23 9y ago
For your own projects, nothing. For me accessing your project, third party validation that a consistent entity exists is worth something.
deleted 9y ago
[deleted]
IncRnd 9y ago
Accepting any self-signed cert that gets presented is the same as not using certs in the first place. Just use http:// http://. If you pre-share or pin self-signed certs that can be useful but in a different use case.
- Jach 9y ago
  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.
  - IncRnd 9y ago
    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:// https:// connection. That is why accepting any self-signed certificates should be treated identically to http:// http:// connections.

sgift 9y ago

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.

LinuxBender 9y ago
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?
- pfg 9y ago
  "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 https://letsencrypt.org/2015/10/29/phishing-and-malware.html [2]: https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/4Xy1Q6PHA7Y/-OcrrsTqCAAJ https://groups.google.com/forum/#!msg/mozilla.dev.security.p... [3]: https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/vMrncPi3tx8/M-U5F8K7AQAJ https://groups.google.com/forum/#!msg/mozilla.dev.security.p...
- temprature 9y ago
  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.
  - LinuxBender 9y ago
    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?
    - tialaramex 9y ago
      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.
- goodplay 9y ago
  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.
  - dawnerd 9y ago
    doesn't the gray padlock currently mean the site isn't 100% secure? Meaning the page itself is but an asset isn't?
    - goodplay 9y ago
      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.
      - mikeash 9y ago
        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.
        tialaramex 9y ago
- technion 9y ago
  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".

steve_taylor 9y ago

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.

0xTJ 9y ago

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.

kyledrake 9y ago

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.

copperx 9y ago
Doesn't IE (or Edge?) show a big green bar if it's one of the highly verified certificates?
- paulddraper 9y ago
  I think all the browsers do. I the UI had the name of the organization too.

evgen 9y ago

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.

deleted 9y ago

[deleted]

advisedwang 9y ago

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.

azernik 9y ago

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.html#rfc.section.10 https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.htm...

protomyth 9y ago
> 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.
- pfg 9y ago
  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.
  - tialaramex 9y ago
    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.
paulddraper 9y ago
> 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.
9y ago

pfg 9y ago

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.

Spooky23 9y ago

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

deleted 9y ago

[deleted]

IncRnd 9y ago

Accepting any self-signed cert that gets presented is the same as not using certs in the first place. Just use http:// http://. If you pre-share or pin self-signed certs that can be useful but in a different use case.

Jach 9y ago
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.
- IncRnd 9y ago
  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:// https:// connection. That is why accepting any self-signed certificates should be treated identically to http:// http:// connections.