Anyone want to drink that Kool-Aid?
When Steve Gibson first started talking about revocation, I never knew it would be such a hot topic right now. Then he decided his next thing he needs to do is talk a bout the CRL’s (Chromium Browser or Chrome). Now before we get into the problem at hand, we first have to understand what CRL’s (Chrome Revocation List’s) are and how they deal with Chrome. I think Steve did a fantastic job at discussion it but we probably are not done with the subject. The Adam Langley decided he needed to talk about what Steve posted. I guess he felt like he was being attacked but he also said stuff that purely got me thinking:
“Since we’re pushing a list of revoked certificates anyway, we would like to invite CAs to contribute their revoked certificates (CRLs) to the list. We have to be mindful of size, but the vast majority of revocations happen for purely administrative reasons and can be excluded. So, if we can get the details of the more important revocations, we can improve user security. Our criteria for including revocations are:
- The CRL must be crawlable: we must be able to fetch it over HTTP and robots.txt must not exclude GoogleBot.
- The CRL must be valid by RFC 5280 and none of the serial numbers may be negative.
- CRLs that cover EV certificates are taken in preference, while still considering point (4).
- CRLs that include revocation reasons can be filtered to take less space and are preferred.”
Breaking down that statement!
I figured this is all about details and we should have a little fun and read between the lines. The first thing that jumps out at me is that the CRLSet’s must not get to big, I’m guessing it has to do with size and they probably are trying to keep it under a certain amount of space. I can only guess it would be close to 10 megabytes but that is just a guess. It isn’t unconventional to say the least but it would be phenomenal if it was better than the revocation checks.
So the Second thing that really makes my eyes pop out is that it can not be encrypted? Which means that if it can not be encrypted then we have a man in the middle attack possible where someone could almost prevent Google from telling browser that a site has revoked their certificates. It is highly unlikely but someone could come along and snatch that CRL before it gets to the browser and easily change it to prevent you from knowing any the wiser. Which means it is a MITM (Man in The Middle Attack) although it is highly unlikely I am going to have to say it is possible! I can not understand the concept of this. You can have bots go to sites that are 100% HTTPS and not have any problems. I am amazed and quite concerned that it has to be HTTP and HTTPS. So it begs the question about why he thinks this is an ideal situation.
I could go on about just that list but I better get to my other points
And yet, GRC managed to write pages (including cartoons!) exposing the fact that it doesn’t cover many revocations and attacking Chrome for it.
They also claim that soft-fail revocation checking is effective:
I’m pretty sure, I’ve talked about soft-fail revocation the last few weeks but I am not the only one who has talk about this. Steve has talked about it in depth on his site also. He seems to think that it will not help and it is not effective but I find that the CRLSet is also very ineffective and should be avoided at all cost. I though did like the cartoons that Steve or I should say GRC posted about the CRLSets and what that means to you!
Revocation is still KEY!
Even though I believe revocation is the heart of the problem, it is still the best we have. I think it will go out the window in the next few years and something better will come but until then we have to come up with a best way to trust that if the certificate is revoked we can know that it isn’t being used. This is where OCSP Stapling comes into play. We can cut out most problems and attacks if we do not allow the connection to refuse a certificate look up. I can’t seem to come up with any other way. Again if you haven’t enabled SSL revocation check, it is time to fix that in Chrome.