

The EFF SSL Observatory - bensummers
http://www.eff.org/observatory

======
tptacek
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.

~~~
quadhome
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?

~~~
tptacek
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
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
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
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
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.

