Browsers and SSL Security - a Race to the Bottom !
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
Comments
Joshua
Jun 4th 2012
1 decade ago
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'.
Dom De Vitto (dom@devitto.com)
Jun 4th 2012
1 decade ago
Mike
Jun 4th 2012
1 decade ago
Thanks,
http://mjddesign.wordpress.com
Matthew
Jun 5th 2012
1 decade ago