SANS ISC: Browsers and SSL Security - a Race to the Bottom ! - Internet Security | DShield

• SANS Site Network
  • Current Site
  • Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

We've received a fair number of questions on today's emergency patch from Microsoft ( https://isc.sans.edu/diary/13366 ), 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://http://isc.sans.edu/diary.html?storyid=12556 ).  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:
http://www.imperialviolet.org/2011/03/18/revocation.html
http://blog.spiderlabs.com/2011/04/certificate-revocation-behavior-in-modern-browsers.html

You'd think after the Diginotar compromise just last year (http://isc.sans.edu/diary.html?storyid=11500 , http://isc.sans.edu/diary.html?storyid=11512 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
Metafore.ca

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.
http://convergence.io/
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'.

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.

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.

Thanks,
http://mjddesign.wordpress.com