Threat Level: green Handler on Duty: Brad Duncan

SANS ISC: Browsers and SSL Security - a Race to the Bottom ! - SANS Internet Storm Center SANS ISC InfoSec Forums

Participate: Learn more about our honeypot network

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Browsers and SSL Security - a Race to the Bottom !

We've received a fair number of questions on today's emergency patch from Microsoft ( ), and many of them have been simply "Why don't they just put the affected Certs into the CRL (Certificate Revocation List)"?  That is, after all, what the CRL is for, and it's part of the SSL protocol for goodness sake!

Simply put, in most cases the browsers do not consult the CRL, or if they do, they time out the lookup and proceed on *very* quickly.  Jim wrote on this in Febuary when Chrome enabled this behaviour ( http:// ).  But this behaviour has been in force for some time (to various degrees) in most browsers an platforms.  A quick google led me to some excellent articles on this topic:

You'd think after the Diginotar compromise just last year ( , and many others), we'd have learned and changed this behaviour.

Unfortunately, it's truly become a race to the bottom for Browsers where SSL security is concerned.  And sadly, it's we, the browser users who insist on "the fastest browser" that have forced them to go there.

Rob VandenBrink

Rob VandenBrink

579 Posts
ISC Handler
Jun 4th 2012
In this particular case, there are attack vectors when the machine is not on the internet, making CRL checking impossible. Patch is required.
Moxy Marlinspike has some excellent youtube presenations on the fundamental problem with our use of SSL, or more correctly, our TRUST in browsers that in turn trust certificate authorities.
Looks to fix some of the problems with SSL, and works today with a simple browser plugin - yeah, and it's very fast and doesn't introduce new vulnerabilities.

If you think SSL is flawed, or you think SSL solves everything, you should read this, because both groups are right 'sortof'.

45 Posts
The biggest concern, what Joshua said in his post, is what happens when the machine is offline. _Most_ browsers, by default, when they can't contact a CRL, just assume that the certificate is good, and not revoked. So a DoS of sorts could be performed against a CRL server, and make the certificate "appear" to be good.

4 Posts
And yet when we have an ssl that has mixed content or there are problems determining the validity of a cert, the browsers make sure to make a clear notifcation that there is an issue to the user. What is the use if the CRL is not checked. Like having a car with airbags but no seatbelts. I am sure there are ways to ensure its use but for the common user they would never know. if we had multiple channels to check revocation then it would take a large distributed attack to ensure all CRL servers were unresponsive.


15 Posts

Sign Up for Free or Log In to start participating in the conversation!