4 ms·

Seriously this. I don't see why encryption and website verification have been wrapped up in the same thing (SSL certs). They're two different things. Encryption

by x0 11y ago

Seriously this. I don't see why encryption and website verification have been wrapped up in the same thing (SSL certs). They're two different things. Encryption should be free, automatic and default.

schoen 11y ago
If you don't have a way to confirm that the key you're seeing from the other site is right, you're inherently vulnerable to a man-in-the-middle attack which removes the benefits of the encryption against the attacker. https://en.wikipedia.org/wiki/Man-in-the-middle_attack https://en.wikipedia.org/wiki/Man-in-the-middle_attack httpS://en.wikipedia.org/wiki/Zooko's_triangle It's not clear that the certificate authority system was or is the best solution to this problem, but it is a problem that calls for some solution. In the case of Domain Validation, we only try to confirm that the key is appropriate to use with the domain name, which is the smallest possible kind of confirmation that can be done to address the crypto problem. There's no attempt to validate or verify anything else about the site.
- cellularmitosis 11y ago
  However, having one and not the other isn't totally useless. Having the browser be able to track and tell me that "Though we aren't sure this is actually google.com, we do know that the exact same cert has been used the last 50 times you visited this website" is something I'd consider to be useful. (Actually, telling me if it changes would be the useful bit). That would be at least be useful for self-signed certs (though those aren't really needed in light of Let's Encrypt...)
  - cyphar 11y ago
    > However, having one and not the other isn't totally useless. > Having the browser be able to track and tell me that "Though we aren't sure this is actually google.com, we do know that the exact same cert has been used the last 50 times you visited this website" is something I'd consider to be useful. (Actually, telling me if it changes would be the useful bit). Isn't that what you do when you make a security exception for a self-signed certificate? Having that enabled by default lulls people into a false sense of security.
  - Pxtl 11y ago
    Be nice if self-signed certs were compatible with vanilla HTTP. Then no warning or complaint from the browser, but minimal security boost over naked transmission.
  - rspeer 11y ago
    > (Actually, telling me if it changes would be the useful bit). I'm curious. Has anyone ever encountered that scary warning you get when an SSH host key changes, and thought "oh man, I'm getting MITMed, I'd better not connect to this server!", instead of thinking "oh right, I guess they reconfigured the server, now what command do I type to make the warning go away"?
    - tomjen3 11y ago
      I have. Usually it's because i reconfigured the server, but I am ultra paranoid. Most people don't care, but I would expect sysadmins to do so. And who else should login with ssh?
    - schoen 11y ago
      I've never thought it was likely to be an attack, but I always thought it was my responsibility to check why it changed or at the very least confirm it looked the same via a separate network path.
  - clinta 11y ago
    Take a look at google's certs. They're only valid for a few months. A system that tracks certificates encourages site operators to share the same cert and key across many servers and to allow it to live for a long time. With the sorry state of certificate revocation this is not ideal. On the server side it's better for each server to have it's own private key and certificate which is valid for a short period of time and frequently renewed. So the compromise of one server does not compromise certificates on any other servers and the useful lifetime of a compromised key is very limited. I think DNSSEC and DANE is the best solution. Allow the certificate thumbprints to be published securely in DNS. At least then we reduce the number of trusted authorities to the TLDs and the scope of authority for each one is automatically restricted to it's own TLD.
cyphar 11y ago
> Seriously this. I don't see why encryption and website verification have been wrapped up in the same thing (SSL certs). They're two different things. Encryption should be free, automatic and default. Becuase you either have to do DH and all of the key negotiation anyway (at which point you already have a key, so why not encrypt and HMAC at the same time?). If you had two systems for this, it would be pointlessly inefficient (why have two DH key exchanges for the same channel).
zurn 11y ago
SSL/TLS actually does support unverified encryption, but browsers have decided to disable it because the UI for "encrypted but non-verified" is deemed too confusing for users. See eg https://bugzilla.mozilla.org/show_bug.cgi?id=220240#c6 https://bugzilla.mozilla.org/show_bug.cgi?id=220240#c6
Ajedi32 11y ago
Because without a trust anchor (a certificate), encryption is pretty much worthless against MitM attacks. You need a way to verify that the site you're connecting to really is who it claims to be before you can trust even an encrypted connection to that site. Otherwise you don't know whether you just established an encrypted connection to the website, or an encrypted connection to a malicious attacker.

by x0 11y ago

Seriously this. I don't see why encryption and website verification have been wrapped up in the same thing (SSL certs). They're two different things. Encryption should be free, automatic and default.

schoen 11y ago

If you don't have a way to confirm that the key you're seeing from the other site is right, you're inherently vulnerable to a man-in-the-middle attack which removes the benefits of the encryption against the attacker. https://en.wikipedia.org/wiki/Man-in-the-middle_attack https://en.wikipedia.org/wiki/Man-in-the-middle_attack httpS://en.wikipedia.org/wiki/Zooko's_triangle It's not clear that the certificate authority system was or is the best solution to this problem, but it is a problem that calls for some solution. In the case of Domain Validation, we only try to confirm that the key is appropriate to use with the domain name, which is the smallest possible kind of confirmation that can be done to address the crypto problem. There's no attempt to validate or verify anything else about the site.

cellularmitosis 11y ago
However, having one and not the other isn't totally useless. Having the browser be able to track and tell me that "Though we aren't sure this is actually google.com, we do know that the exact same cert has been used the last 50 times you visited this website" is something I'd consider to be useful. (Actually, telling me if it changes would be the useful bit). That would be at least be useful for self-signed certs (though those aren't really needed in light of Let's Encrypt...)
- cyphar 11y ago
  > However, having one and not the other isn't totally useless. > Having the browser be able to track and tell me that "Though we aren't sure this is actually google.com, we do know that the exact same cert has been used the last 50 times you visited this website" is something I'd consider to be useful. (Actually, telling me if it changes would be the useful bit). Isn't that what you do when you make a security exception for a self-signed certificate? Having that enabled by default lulls people into a false sense of security.
- Pxtl 11y ago
  Be nice if self-signed certs were compatible with vanilla HTTP. Then no warning or complaint from the browser, but minimal security boost over naked transmission.
- rspeer 11y ago
  > (Actually, telling me if it changes would be the useful bit). I'm curious. Has anyone ever encountered that scary warning you get when an SSH host key changes, and thought "oh man, I'm getting MITMed, I'd better not connect to this server!", instead of thinking "oh right, I guess they reconfigured the server, now what command do I type to make the warning go away"?
  - tomjen3 11y ago
    I have. Usually it's because i reconfigured the server, but I am ultra paranoid. Most people don't care, but I would expect sysadmins to do so. And who else should login with ssh?
  - schoen 11y ago
    I've never thought it was likely to be an attack, but I always thought it was my responsibility to check why it changed or at the very least confirm it looked the same via a separate network path.
- clinta 11y ago
  Take a look at google's certs. They're only valid for a few months. A system that tracks certificates encourages site operators to share the same cert and key across many servers and to allow it to live for a long time. With the sorry state of certificate revocation this is not ideal. On the server side it's better for each server to have it's own private key and certificate which is valid for a short period of time and frequently renewed. So the compromise of one server does not compromise certificates on any other servers and the useful lifetime of a compromised key is very limited. I think DNSSEC and DANE is the best solution. Allow the certificate thumbprints to be published securely in DNS. At least then we reduce the number of trusted authorities to the TLDs and the scope of authority for each one is automatically restricted to it's own TLD.

cyphar 11y ago

> Seriously this. I don't see why encryption and website verification have been wrapped up in the same thing (SSL certs). They're two different things. Encryption should be free, automatic and default. Becuase you either have to do DH and all of the key negotiation anyway (at which point you already have a key, so why not encrypt and HMAC at the same time?). If you had two systems for this, it would be pointlessly inefficient (why have two DH key exchanges for the same channel).

zurn 11y ago

SSL/TLS actually does support unverified encryption, but browsers have decided to disable it because the UI for "encrypted but non-verified" is deemed too confusing for users. See eg https://bugzilla.mozilla.org/show_bug.cgi?id=220240#c6 https://bugzilla.mozilla.org/show_bug.cgi?id=220240#c6

Ajedi32 11y ago

Because without a trust anchor (a certificate), encryption is pretty much worthless against MitM attacks. You need a way to verify that the site you're connecting to really is who it claims to be before you can trust even an encrypted connection to that site. Otherwise you don't know whether you just established an encrypted connection to the website, or an encrypted connection to a malicious attacker.