Tuesday, December 23, 2008

Traffic for Revoked TLSv1 Certificate

I read the Slashdot post Perfect MITM Attacks With No-Check SSL Certs with some interest, mainly from a traffic perspective. Basically Eddy Nigg managed to obtain a certificate for a domain he should not have had access to via a reseller for a company called Comodo. You can check your Firefox certificate authorities list to see their presence in the screenshot below.



Eddy managed to get a certificate allowing him to masquerade as mozilla.com, because the party issuing the certificate did not properly validate his authorization to act on behalf of mozilla.com.

I wondered what this might look like when I read this comment suggesting visiting a site using a Comodo-provided certificate. When I visited I saw this:



The question is, how did Firefox know to avoid this problem? I decided to sniff traffic while revisiting the site. Here's what happened.



The first session of interest is from client 24.126.62.67 to Comodo-certificate-possessing Web server 192.116.242.23. The second session of interest is from client 24.126.62.67 to Online Certificate Status Protocol (OSCP) server 91.199.212.169.

So, in frames 36-51 you see the setup of a TLSv1 session with the Web server. Frame 49 shows the certificate presented by the Web server.



In frames 52 and 53 we see a DNS query and response for ocsp.comodoca.com. In frames 54-58 and 62-67 we see our Web browser checking the status of the certificate we received from the Web server. Frame 64 shows the OCSP replying that the certificate has been revoked.



This leads to frame 68 where we see the TLSv1 connection fail due to the revoked certificate.



After that the connections close.

Taking a closer look at Firefox settings, we find this is what controls OCSP, and these are the defaults.



Taking a closer look at the cert we see it does specify an OCSP server, which shows how our browser knew to try to find it.



I am not sure how other certificates set this part of their certs, but it would be easy to find out.

This scenario just demonstrates the importance of trust, but also rapid detection and response when that trust is violated. Building visibility in through monitoring and validation mechanisms like OCSP (but perhaps to a third party rather than the company duped into issuing a cert!) are good lessons here.


Richard Bejtlich is teaching new classes in DC and Europe in 2009. Register by 1 Jan and 1 Feb, respectively, for the best rates.

1 comment:

CMoi said...

Something worries me on your screenshot. The option to consider the certificate invalid when connection to OCSP server fails is unchecked!
So you just have to ensure the guy cannot connect to the server...