Image courtesy of marfis75 at Flickr (CC BY-SA 2.0)
I visited a client to discuss SSL/TLS this week, as well as the many associated elements that make the whole system work; PKIs, cryptography and so on. Coincidentally, when I arrived home that same day I noticed an article over at The Register that suggested that some proof of concept JavaScript code named "BEAST", or Browser Exploit Against SSL/TLS, could be paired with a packet sniffer to ultimately decrypt encrypted cookies regardless of the fact that HTTPS is in use and even when HTTP Strict Transport Security (HSTS) is in use.
While interesting, the article is a little misleading in parts. Details are limited about BEAST, but one part of a sentence in the first page of the article ("an attacker slips a bit of JavaScript into your browser, and the JavaScript collaborates with a network sniffer to undermine your HTTPS connection") seems to suggest that this may not be flaw in SSL/TLS per se, but a flaw in elements that are related to how we use SSL/TLS - i.e. the browser. There appears to be a requirement for some sort of user interaction to facilitate the attack. Thai Duong and Juliano Rizzo plan to present their proof-of-concept code at the Ekoparty security conference in Buenos Aires later this week; it will be interesting to see the result.
Maybe more interesting because we now have a more complete understating of events is the discussion of the recent man-in-the-middle attacks against Google users in the same article.
Once again, this is not an example of a broken system (certificates and PKIs are fine!), but an example of part of a system being managed improperly. Follow the rules, and the system as a whole operates as expected. Introduce a weak link, and there will invariably be someone ready an willing to exploit that vulnerable element. My house is relatively secure if I don't share the key or make copies and given them away. If I leave the key under a flower pot (I don't!), I weaken the security of the system.
Given the desire to ensure a stable user experience, machine trusted root certification authority stores contain root certificates from many companies that you may have heard of, as well as many that are perhaps less familiar to you. By trusting root authorities "out of the box", and relying on vendors to ensure participants in their "trust programs" are worthy of such trust, we benefit by being more assured than we otherwise could be that the remote party on the other end of an HTTPS connection is actually who it (the server) says it is. The Google blog post linked above reads: "The attacker used a fraudulent SSL certificate issued by DigiNotar, a root certificate authority that should not issue certificates for Google (and has since revoked it)." Put differently, DigiNotar (a Dutch certificate authority owned by an Illinois based company) issued a certificate to an entity claiming to be Google, who were not Google. Wired has a great account of what happened, and illustrates the one possible outcome for companies when security is sacrificed or ignored - bankruptcy. When you are a central point in a trust hierarchy and can no longer be trusted, the effects are likely to be devastating. The security behind the model is not broken, there were simply critical gaps in the controls that DigiNotar had in place. For example, to be bundled as a trusted root in Microsoft's Windows Root Certificate Program, you need to meet very specific requirements. According to the Wired article that discusses DigiNotar, many of these did not appear to be in place.
With limited oversight of practices and no requirement for audit from a central authority or regulatory body, there will always be a risk that some authorities may serve as a weak link. Thankfully, as Google's account of the issue suggests, the techniques to detect this kind of abuse continue to improve. Let this also serve as a lesson for CAs and for users/administrators:
- For certificate authorities? Trust needs to be earned, and just as in life actions you take can irrevocably damage that trust.
- For administrators and users? Think carefully about who you add to your trusted root certificate authority stores!