5 ms·

The EFF SSL Observatory

39 points by bensummers 16y ago

tptacek 16y ago
SSL is a fine protocol, but it's been badly misconfigured on the Internet. Among other things: * The overwhelming majority of SSL-speaking sites don't have valid certificates. * An untenably large number of organizations have been allowed to act as CAs. * Some of those CA's have in turn been allowed to set up sub-CA's. * Several CA's use cryptographically weak keys * Some CA's were spotted sharing keys * CA's have signed certs for RFC1918 private IP space, sometimes more than once. * CA's have signed certs for "localhost" The bad news is that all these things are devastating to the global security of SSL/TLS. The good news is that fixing them doesn't involve a change to SSL/TLS, or even any of the software that implements it. The bad news is that's unlikely to happen in our lifetimes.
- arethuza 16y ago
  Excellent points - I'm always dismayed at the number of people who equate SSL with "secure" and fail to appreciate what kinds of "security" SSL gives and what that depends on (e.g. the checks made by a CA to authenticate identity, which are often minimal) or where it can break down (e.g. you may not have end to end security in some environment even though you think you do).
  - Timothee 16y ago
    The problem is that everybody has been taught that SSL does mean "secure". "Look for the lock icon", "make sure it says https and not http" and so on. Which in the end is a good thing because people have been made aware of some security problems that way. The great thing about HTTPS is that it's mostly managed by the browser and looking for the lock or checking the URL is easy enough for anyone to do. But what can one do to make sure they're secure once they checked the basic things they've been taught?
- quadhome 16y ago
  How you would have configured SSL (or the PKI, as seems to be the problem) for the Internet? Do you think a global, managed and secure PKI is feasible?
  - jerf 16y ago
    "Do you think a global, managed and secure PKI is feasible?" Do you think it is possible for a third party completely unrelated to you to correctly decide who you do and do not trust? Do you think it is possible for a couple hundred such third parties? Your question is nearly equivalent to mine. Security just can't be made zero-effort, in my opinion. You can only get psuedosecurity for zero effort, which is what we have now. Might even be better than nothing; at least SSL constrains the number of entities that can trivially sniff your traffic to the two endpoints and any MitM that manages to wedge itself in (which isn't impossible but takes effort), which is at least a bona fide reduction in attack surface.
    - tptacek 16y ago
      In 2010, MITM attackers are the default. It takes only marginal additional effort to intercept SSL traffic. Attackers don't sniff anymore. The disconnect between people implementing SSL --- who appear to be permanently stuck in 1997 --- and the people dealing with actual attacks is... frustrating.
  - tptacek 16y ago
    Yes, I do think it's feasible to solve the authentication problem SSL is aiming to solve. I think the overwhelming majority of the challenge with SSL is UI-driven, and that any security solution attempted at Internet scale will need to address that same problem. Specifically: * Nobody has come up with a user-comprehensible abstraction to represent the machinery needed to represent the chain of actors needed to assert that "this is really Bank of America". Instead, we wound up with a buried configuration box that says "Verisign is God." * An obvious corrollary: there shouldn't be a single global set of browser-accepted root certificates. End-users should subscribe to CA's as needed (again: the UI abstractions aren't there yet to make this doable). The IETF should come up with a process to run a CA to certify and name other CA's. * It shouldn't be possible to easily click through warnings about invalid certificates, since that warning amounts to "there is no security provided by SSL on this connection." Implementing this would require service operators to have better ways of making sure their certs were valid. All this stuff sounds highly dramatic, but I want to remind you that none of these changes would alter the SSL protocol or any of its implementations (OpenSSL, NSS, SCHANNEL, etc).
- gojomo 16y ago
  How does someone best protect themself, given this state-of-affairs? (Is there some subset of CAs doing the right things?) Is the situation with 'EV' certificates any better, excluding some of the worst-practices you've highlighted?
  - tptacek 16y ago
    It doesn't matter, since so many of the Internet's most popular sites are signed by crappy CA's; right now, you have to honor most certs.

39 points by bensummers 16y ago

SSL is a fine protocol, but it's been badly misconfigured on the Internet. Among other things: * The overwhelming majority of SSL-speaking sites don't have valid certificates. * An untenably large number of organizations have been allowed to act as CAs. * Some of those CA's have in turn been allowed to set up sub-CA's. * Several CA's use cryptographically weak keys * Some CA's were spotted sharing keys * CA's have signed certs for RFC1918 private IP space, sometimes more than once. * CA's have signed certs for "localhost" The bad news is that all these things are devastating to the global security of SSL/TLS. The good news is that fixing them doesn't involve a change to SSL/TLS, or even any of the software that implements it. The bad news is that's unlikely to happen in our lifetimes.

arethuza 16y ago
Excellent points - I'm always dismayed at the number of people who equate SSL with "secure" and fail to appreciate what kinds of "security" SSL gives and what that depends on (e.g. the checks made by a CA to authenticate identity, which are often minimal) or where it can break down (e.g. you may not have end to end security in some environment even though you think you do).
- Timothee 16y ago
  The problem is that everybody has been taught that SSL does mean "secure". "Look for the lock icon", "make sure it says https and not http" and so on. Which in the end is a good thing because people have been made aware of some security problems that way. The great thing about HTTPS is that it's mostly managed by the browser and looking for the lock or checking the URL is easy enough for anyone to do. But what can one do to make sure they're secure once they checked the basic things they've been taught?
quadhome 16y ago
How you would have configured SSL (or the PKI, as seems to be the problem) for the Internet? Do you think a global, managed and secure PKI is feasible?
- jerf 16y ago
  "Do you think a global, managed and secure PKI is feasible?" Do you think it is possible for a third party completely unrelated to you to correctly decide who you do and do not trust? Do you think it is possible for a couple hundred such third parties? Your question is nearly equivalent to mine. Security just can't be made zero-effort, in my opinion. You can only get psuedosecurity for zero effort, which is what we have now. Might even be better than nothing; at least SSL constrains the number of entities that can trivially sniff your traffic to the two endpoints and any MitM that manages to wedge itself in (which isn't impossible but takes effort), which is at least a bona fide reduction in attack surface.
  - tptacek 16y ago
    In 2010, MITM attackers are the default. It takes only marginal additional effort to intercept SSL traffic. Attackers don't sniff anymore. The disconnect between people implementing SSL --- who appear to be permanently stuck in 1997 --- and the people dealing with actual attacks is... frustrating.
- tptacek 16y ago
  Yes, I do think it's feasible to solve the authentication problem SSL is aiming to solve. I think the overwhelming majority of the challenge with SSL is UI-driven, and that any security solution attempted at Internet scale will need to address that same problem. Specifically: * Nobody has come up with a user-comprehensible abstraction to represent the machinery needed to represent the chain of actors needed to assert that "this is really Bank of America". Instead, we wound up with a buried configuration box that says "Verisign is God." * An obvious corrollary: there shouldn't be a single global set of browser-accepted root certificates. End-users should subscribe to CA's as needed (again: the UI abstractions aren't there yet to make this doable). The IETF should come up with a process to run a CA to certify and name other CA's. * It shouldn't be possible to easily click through warnings about invalid certificates, since that warning amounts to "there is no security provided by SSL on this connection." Implementing this would require service operators to have better ways of making sure their certs were valid. All this stuff sounds highly dramatic, but I want to remind you that none of these changes would alter the SSL protocol or any of its implementations (OpenSSL, NSS, SCHANNEL, etc).
gojomo 16y ago
How does someone best protect themself, given this state-of-affairs? (Is there some subset of CAs doing the right things?) Is the situation with 'EV' certificates any better, excluding some of the worst-practices you've highlighted?
- tptacek 16y ago
  It doesn't matter, since so many of the Internet's most popular sites are signed by crappy CA's; right now, you have to honor most certs.