09 Aug 2012
The IETF is in a pickle again. The security conscious folks would very much like to make TLS the norm for HTTP/2.0, but there is this little problem of certificate management. TLS requires that the server presents a public key certificate. Browsers like IE9 only trust the certificate if it is signed by a certification authority, but getting a signature like that costs money. A few hundred dollars here or there is not a problem for the big sites, but it is a significant expense for the smaller folks. They prefer a simpler solution, deploying TLS with "self-signed" certificates, which they can manufacture freely. But then, self-signed certificates are not all that secure…
Suppose that www.example.com tries to secure its TLS connections with a self-signed certificate. Alice clicks on the link, but a hacker managed to pollute her DNS server, and the request is redirected to a hacker-controlled server. That server can provide its own self signed certificate. Alice sees a "secure" connection, and believes she is landing at the right place, but her connection is really controlled by the attacker. Many see that as a fatal flaw of the "self-signed certificate" approach. The simple analysis is "self-signed bad, authority-signed good." But things are not so simple.
Self-signed certificates do have some advantages over plain text connections, since the data is encrypted. The forging of the site's certificate requires an active attack: hacking the DNS, forcing the client to use an untrusted proxy, or somehow affecting the routing of IP packets. In the absence of active attacks, the encryption will protect against passive eavesdropping. Since non-encrypted connection can also be affected by active attacks, it would seem that self-signed TLS only has advantages over plain text HTTP. The main disadvantage are in the realm of psychology. The client might come to trust the encryption and take more risks than with a plain text exchange.
The counterpoint to that argument is that authority-signed certificates are not entirely secure either. I discussed that in a previous post, The Comodo Hacker, PKI and Internet Standards. Hackers can compromise TLS by obtaining a fake certificate, either from a rogue authority or through some compromised service. In that post, I proposed a set of solutions, based on the user's password, a shared secret between the site and the user. We can devise exchanges that provide mutual authentication by proving to both parties that they know the password. We can also use the password exchange to verify that the TLS exchange has not been compromised. It requires some work on standards, and some sharp use of cryptography, but it is entirely doable today.
The good news is that the password-based proofs would also prevent the hacks against the self-signed certificates. I have not attended the IETF for some time, I do not relish the idea of engaging in one more long standardization slog, and my current job description at Microsoft does not include spending time at the IETF. But securing the Internet is a really important outcome. I will have to find a way…