From 0wning DNS to 0wning SSL (2/2)

But SSL does have an Achilees heel: its trust model is anchored on the digital certificate used by the web server: the only proof that the website you are communicating with Bank of America (as opposed to an impostor in Estonia) is the fact that they have a digital certificate issued by Verisign claiming that this website indeed is

The fragility of this model has been pointed out before. Verisign is not the only recognized certification authority; out of the box Windows ships with close to 100 CAs, all of them equivalent for trust purposes. Any one of them incorrectly issuing the Bank of America certificate to somebody else is enough to ruin any guarantees provided by the cryptography– it does no good to secure your traffic, when the person at the end of that encrypted channel is the bad guy. (Perhaps the biggest CA goof was Verisign issuing Microsoft code-signing certificate to impostors in 2001. The implications were much worse than for SSL certificates, but revocation has addressed the fall-out for the most part.) While MITM attacks against SSL due to incompetent CA practices have always been possible, the challenge of playing that messenger in between so far made this a low-likelihood attack vector. Owning DNS changes that.

More importantly– and this is Kaminsky’s main point regarding SSL– the certification process itself uses DNS. According to this version of the story, when the proud new owner of the domain wants a digital certificate, the CA consults DNS records to verify ownership. They might even ask the user to insert some DNS records or add a particular page to the website, as additional proof. All of these checks are trivially subverted if DNS is corrupt because all of them will be routed to servers controlled by the attacker. This means that while the existing Bank Of America certificate is safe and sound, the enterprising criminal will:

  1. Choose a moderaly incompetent CA
  2. Subvert DNS to confuse name resolution for that CA
  3. Pass the domain ownership checks made by the CA
  4. Obtain a new valid certificate in the name of Bank of America
  5. Subvert DNS resoution for an ISP
  6. MITM all of the users at that ISP by using the perfectly valid certificate from step #4

That, at least is the picture painted in the presentation. The critical details are certification steps used– not just by Verisign, Geotrust and other major CAs but every single one of the dozens of certification authorities recognized by IE and Firefox. Extended validation does not help for two reasons: on the usability front, users pay no attention to all the fancy eye-candy browsers waste on displaying EV status, as demonstrated nicely by The emperor’s new security indicators.. On the the implementation level, the browser grants exactly same privilege to regular certificates; embedded content for example can still be subverted using a vanilla cert while keeping the main page over EV.

If this attack does indeed work– and it is impossible to determine without consulting the certification practices for CAs– it shows a circularity in the security model. SSL/TLS are designed to survive exactly the type of mayhem created by DNS hijacking. It does not matter whether traffic is routed to the right website or the wrong one. When the protocol is implemented correctly and the certificate checks out, the user is supposed to be guaranteed that they are dealing with the legitimate website. (That is not much of a guarantee: if the certificate has errors, the protocol will detect it but until recent web browsers used to respond by displaying a cryptic warning that users simply ignored. Even when the certificate is validated correctly, that only proves the identity is what is stated in the URL– which may not be at all the same one that is in the user’s mental picture, to the delight of phishing syndicates everywhere.) Weak certification practices destroy even this glimmer of hope by placing critical faith in DNS to bootstrap a protocol that was purportedly designed to survive complete breakdown of all naming and routing infrastructure.


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s