Browsers and SSL Security - a Race to the Bottom !

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	Rob VandenBrink 530 Posts ISC Handler
Subscribe	Jun 4th 2012 7 years ago
In this particular case, there are attack vectors when the machine is not on the internet, making CRL checking impossible. Patch is required.	Anonymous
Quote	Jun 4th 2012 7 years ago
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'.	DomMcIntyreDeVitto 41 Posts
Quote	Jun 4th 2012 7 years ago
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.	MikeDawg 4 Posts
Quote	Jun 4th 2012 7 years ago
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	Matthew 15 Posts
Quote	Jun 5th 2012 7 years ago

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

Rob VandenBrink

530 Posts
ISC Handler

In this particular case, there are attack vectors when the machine is not on the internet, making CRL checking impossible. Patch is required.

Anonymous

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'.

DomMcIntyreDeVitto

41 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.

MikeDawg

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.

Thanks,
http://mjddesign.wordpress.com

Matthew

15 Posts