4 ms·

The encryption part is easy -- you don't need CAs for that -- but they're a necessary evil when it comes to verifying ownership. You need to delegate trust to s

by elahd 9y ago

The encryption part is easy -- you don't need CAs for that -- but they're a necessary evil when it comes to verifying ownership. You need to delegate trust to someone, otherwise using the internet becomes too cumbersome.

ocdtrekkie 9y ago
Automated SSL providers effectively mitigate the idea of "verifying ownership" or "delegating trust", because for example, someone can buy a domain like... googIe.com, get an SSL cert for it, and it's "valid". We're right back to the same level of security of you just checking that the browser bar points at the domain you actually intended to go to. (In this example, bear in mind, Google doesn't use an EV cert, so they'd be equally valid to a web browser. And a lot of EV certs I believe are getting distrusted soon as it is.) CAs seem like a system that really doesn't work today, we've seen multiple times that many of these CAs aren't worth delegating trust to to begin with, and it causes an unnecessary cost and burden upon just... encrypting traffic.
- floatboth 9y ago
  > someone can buy a domain like... googIe.com, get an SSL cert for it, and it's "valid" Are you sure that all "old school" CAs wouldn't issue a cert for that? They were never supposed to fight phishing. Domain Validation certificates literally validate… domains, and nothing more. It would make more sense to prevent googIe.com from existing at the .com registry level, before any TLS is involved.
- elahd 9y ago
  I wasn't referring to EV certificates, just to verifying simple ownership of the domain for the purposes of MITM and other attacks of that kind. Let's Encrypt would inform you that the page that appears when you visit googIe.com was indeed served by the owner of that domain (barring server compromises or cert leaks, but that's a separate issue). LE and "basic" certificates do not attempt to answer the question of who owns the domain -- that's also an entirely separate problem.
- vertex-four 9y ago
  > We're right back to the same level of security of you just checking that the browser bar points at the domain you actually intended to go to. So you’re sitting in a cafe, and you go to Facebook.com. Lo and behold, someone’s installed a MITM proxy on the router, that presents its own encryption key instead of Facebook’s, and your browser has no way to tell this because the CA system isn’t a thing. They now have your password, can steal your session to spam your friends, whatever else. How do you prevent that? Automated domain validated certificates are meant to ensure that when you go to Facebook.com, you’re talking to Facebook.com and not a MITMing router on the way there. They’re not meant to protect against phishing - they’re meant to protect against the very real cases I’ve seen where my mobile ISP adds random JavaScript into the web pages I view, and sells information about me based on my use of the web.
  - Karunamon 9y ago
    Idea that's been floated before: TOFU plus a distributed network of people automatically sharing what cert fingerprints they encounter. Chances are high that you already hit Facebook on your $device, and if you all of a sudden retrieved a certificate that didn't match the one you had before, or that most other people online hadn't seen, halt and throw up the warnings. Given the exploitability, laziness, general failure to follow best practices, not to mention misaligned incentives that we're seeing from major CA vendors, having centralized CAs seems like an ever-worsening solution.
    - amaccuish 9y ago
      And how would rollover work?
      - Karunamon 9y ago
        It would wind up being visible to a large chunk of users simultaneously. Furthermore, since we're relying on the wisdom of the crowd rather than a true CA, you'd be able to trust companies' own CAs rather than delegating off to a not-so-trusted third party. In other words, if someone claiming to be Facebook has told a significant number of people all over the world that Facebook's cert fingerprint is ABCD124, and that fingerprint matches what they're getting presented, it's probably legitimate. We can add additional points for the cert signer being the same one as the previous cert, lack of listing in a CRL, cert transparency logs, etc. There's no reason this system couldn't bolt on top of the existing CA infrastructure to avoid a bootstrapping problem either. It adds a probability value into the mix, in other words. That value has always existed, but now we expose it to the user in some way and stop pretending that it does not.

by elahd 9y ago

ocdtrekkie 9y ago

Automated SSL providers effectively mitigate the idea of "verifying ownership" or "delegating trust", because for example, someone can buy a domain like... googIe.com, get an SSL cert for it, and it's "valid". We're right back to the same level of security of you just checking that the browser bar points at the domain you actually intended to go to. (In this example, bear in mind, Google doesn't use an EV cert, so they'd be equally valid to a web browser. And a lot of EV certs I believe are getting distrusted soon as it is.) CAs seem like a system that really doesn't work today, we've seen multiple times that many of these CAs aren't worth delegating trust to to begin with, and it causes an unnecessary cost and burden upon just... encrypting traffic.

floatboth 9y ago
> someone can buy a domain like... googIe.com, get an SSL cert for it, and it's "valid" Are you sure that all "old school" CAs wouldn't issue a cert for that? They were never supposed to fight phishing. Domain Validation certificates literally validate… domains, and nothing more. It would make more sense to prevent googIe.com from existing at the .com registry level, before any TLS is involved.
elahd 9y ago
I wasn't referring to EV certificates, just to verifying simple ownership of the domain for the purposes of MITM and other attacks of that kind. Let's Encrypt would inform you that the page that appears when you visit googIe.com was indeed served by the owner of that domain (barring server compromises or cert leaks, but that's a separate issue). LE and "basic" certificates do not attempt to answer the question of who owns the domain -- that's also an entirely separate problem.
vertex-four 9y ago
> We're right back to the same level of security of you just checking that the browser bar points at the domain you actually intended to go to. So you’re sitting in a cafe, and you go to Facebook.com. Lo and behold, someone’s installed a MITM proxy on the router, that presents its own encryption key instead of Facebook’s, and your browser has no way to tell this because the CA system isn’t a thing. They now have your password, can steal your session to spam your friends, whatever else. How do you prevent that? Automated domain validated certificates are meant to ensure that when you go to Facebook.com, you’re talking to Facebook.com and not a MITMing router on the way there. They’re not meant to protect against phishing - they’re meant to protect against the very real cases I’ve seen where my mobile ISP adds random JavaScript into the web pages I view, and sells information about me based on my use of the web.
- Karunamon 9y ago
  Idea that's been floated before: TOFU plus a distributed network of people automatically sharing what cert fingerprints they encounter. Chances are high that you already hit Facebook on your $device, and if you all of a sudden retrieved a certificate that didn't match the one you had before, or that most other people online hadn't seen, halt and throw up the warnings. Given the exploitability, laziness, general failure to follow best practices, not to mention misaligned incentives that we're seeing from major CA vendors, having centralized CAs seems like an ever-worsening solution.
  - amaccuish 9y ago
    And how would rollover work?
    - Karunamon 9y ago
      It would wind up being visible to a large chunk of users simultaneously. Furthermore, since we're relying on the wisdom of the crowd rather than a true CA, you'd be able to trust companies' own CAs rather than delegating off to a not-so-trusted third party. In other words, if someone claiming to be Facebook has told a significant number of people all over the world that Facebook's cert fingerprint is ABCD124, and that fingerprint matches what they're getting presented, it's probably legitimate. We can add additional points for the cert signer being the same one as the previous cert, lack of listing in a CRL, cert transparency logs, etc. There's no reason this system couldn't bolt on top of the existing CA infrastructure to avoid a bootstrapping problem either. It adds a probability value into the mix, in other words. That value has always existed, but now we expose it to the user in some way and stop pretending that it does not.