Predictably Random

Fixing SSL flaws

Just in case you missed it; a very serious security breach occurred recently at DigiNotar, a dutch certificate authority. At least 531 fraudulent certificates were issued by the attacker for a wide variety of SSL/TLS secured sites including Gmail, Facebook and the Tor project. Some of those certificates have been used in man-in-the-middle (MITM) attack on Iranian citizens.

One of the effects of this event, and the earlier Comodo breach, has been a renewed discussion on “fixing” SSL because it’s broken. Ignoring the argument of whether SSL is “broken” or just flawed, so far I seen two basic themes to the proposals.

The first is decentralise the trust relationship. Solutions like Perspectives and Convergence introduce the concept of “notaries”. Notaries monitor the use of certificates on sites over time. A user chooses which notary or notaries they trust; when accessing a SSL secured site, the notary is contacted to verify the server certificate presented to the browser.

Which makes we wonder why not do away with the notaries altogether. The recent implementation of uChat, a peer-to-peer chat application built on bittorrent. Using magnet links for each site, swarms could assemble to clients distributed around the world to compare the certificates being presented to each. All this could be built directly into the browser.

The second is to increase the cost of attacks against certificate authorities by have multiple independent certificate authorities sign a certificate. This would require an attacker to compromise multiple certificate authorities simultaneously to issue a fraudulent certificate.

Avoiding any discussion on the relative security of the two models for the moment. I contend it’s the second approach that will prevail. Why? Performance.

A lot of work has been going of recently to reduce the latency of creating new secured connections. Technologies like session resumption, FalseStart, SnapStart, and OSCP stapling are all designed to reduce the number of round trips to create a connection. Decentralising the trust relationship doesn’t just introduce many more rounds trips than were required in the past, it introduces round trips to multiple new locations.

Compounding the problem of a poor user experience, I also contend that a distributed trust model is more vulnerable to state level censorship. When the communication required to establish a new secured session is restricted to that between the client and the server (baring fraudulent certificates) a state level actor is contained to denial of service.

However, in a distributed model the state level actor has the possibility of allowing access to the service but denying access to any notaries or peers outside the censored region. Thus the client, and ultimately the user, is afforded the option of accessing the service but without any guarantees as to the security of the site. We all know how well users pay attention to warning messages today.

I believe this to be a significant weakness of the distributed trust model. A denial of service attack on the SSL validation infrastructure is potentially far more damaging than a denial of service attack on a service its self.

It will be interesting to watch dialogue in this space develop. There are a lot of talented security professionals I’ve yet to see comment such as Bruch Schneier and Adam Langley. Let’s hope as few people as possible get hurt until a solution is found.