5 ms·

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).
- moobot 16y ago
  My biggest complaint with the SSL CA chain of trust is the way that self-signed certificates are (mis)handled. The connection is still an encrypted, "secure" connection to the server; it's the server's identity that is in question, and there's rarely any distinction made to the user about that. I don't want to have to pay or verify my identity to run my own SSL-secured mail server, IRC bouncer, or similar service. Why should I need to? But if I don't, then just about every SSL client in the world falls down and sucks its thumbs or screams bloody murder at me because my certificate isn't signed by the holy gatekeepers...
  - tptacek 16y ago
    No, this is pretty much dead wrong. An SSL connection set up under a self-signed cert is not "secure". Authentication isn't a feature of a secure channel, it's a requirement. Without it, marginal effort by an attacker allows them to silently, quickly, and transparently decrypt your traffic by inserting themselves in the middle. People on HN can and do argue about this until they are blue in the face, but the fact of the matter is that authenticated connections aren't just a special "bonus" that SSL provides beyond encryption. Every secure encrypted protocol makes arrangements to authenticate keys; this is the same thing that makes your first SSH connection to a new server insecure (demonstrating that problem used to be a sport at security conventions).
    - moobot 16y ago
      If I'm verifying the fingerprint of the server's certificate, is that not doing the same thing that the chain of trust would be doing?
      - tptacek 16y ago
        Nobody is really verifying the fingerprint of the server's certificate, but if you are, fine; you and I are talking about two different issues. You're talking about your own homebrew setup that uses the SSL protocol and manual certificate verification (incidentally, just set up your own CA and forget about the fingerprints; it's not hard). I'm talking about Internet-scale secure web connections to banks.

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

moobot 16y ago
My biggest complaint with the SSL CA chain of trust is the way that self-signed certificates are (mis)handled. The connection is still an encrypted, "secure" connection to the server; it's the server's identity that is in question, and there's rarely any distinction made to the user about that. I don't want to have to pay or verify my identity to run my own SSL-secured mail server, IRC bouncer, or similar service. Why should I need to? But if I don't, then just about every SSL client in the world falls down and sucks its thumbs or screams bloody murder at me because my certificate isn't signed by the holy gatekeepers...
- tptacek 16y ago
  No, this is pretty much dead wrong. An SSL connection set up under a self-signed cert is not "secure". Authentication isn't a feature of a secure channel, it's a requirement. Without it, marginal effort by an attacker allows them to silently, quickly, and transparently decrypt your traffic by inserting themselves in the middle. People on HN can and do argue about this until they are blue in the face, but the fact of the matter is that authenticated connections aren't just a special "bonus" that SSL provides beyond encryption. Every secure encrypted protocol makes arrangements to authenticate keys; this is the same thing that makes your first SSH connection to a new server insecure (demonstrating that problem used to be a sport at security conventions).
  - moobot 16y ago
    If I'm verifying the fingerprint of the server's certificate, is that not doing the same thing that the chain of trust would be doing?
    - tptacek 16y ago
      Nobody is really verifying the fingerprint of the server's certificate, but if you are, fine; you and I are talking about two different issues. You're talking about your own homebrew setup that uses the SSL protocol and manual certificate verification (incidentally, just set up your own CA and forget about the fingerprints; it's not hard). I'm talking about Internet-scale secure web connections to banks.