The EFF SSL Observatory(eff.org)
eff.org
The EFF SSL Observatory
http://www.eff.org/observatory
15 comments
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?
Do you think a global, managed and secure PKI is feasible?
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).
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).
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...
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...
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).
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).
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?
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.
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.
Isn't this a good thing? I'm not sure its possible to represent the mechanism in any other way that doesn't involve actually having to teach users about how SSL works.
Isn't this a good thing? I'm not sure its possible to represent the mechanism in any other way that doesn't involve actually having to teach users about how SSL works.
There must exist something in between sharing nothing with end-users (the situation we have now, where sites are literally either "secure" or "not" --- and, incidentally, a situation that DNSSEC actually makes worse) and sharing ServerKeyExchange and CertificateRequest messages.
My guess is that the answer will involve having something more meaningful than the name "Verisign" at the root of the certificate change. "Secure Banking Sites", which ideally would be managed by (wait for it) secure banking sites, sounds better.
We can get to that world without forklifting out OpenSSL.
My guess is that the answer will involve having something more meaningful than the name "Verisign" at the root of the certificate change. "Secure Banking Sites", which ideally would be managed by (wait for it) secure banking sites, sounds better.
We can get to that world without forklifting out OpenSSL.
"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.
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.
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.
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).
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?
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?
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?
Is the situation with 'EV' certificates any better, excluding some of the worst-practices you've highlighted?
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.
* 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.