What Your Browser Doesn’t Tell You Can Hurt You – Revocation and Internet Explorer

One of the topics I have been using as an example of revocation checking behavior in my PKI In-Depth class is the interesting case of Internet Explorer (IE) and its revocation behavior. Let’s take a moment and have you think about your assumption of how IE is behaving when you go to a HTTPS (SSL/TLS) website. The general assumption is that the TLS certificate is downloaded from the web server, the URL entered is compared to the Subject/Subject Alternate Name extensions to ensure we arrived at the right site and haven’t been redirected. The browser should go on and validate additional information like validity period, key usage, and of course assembling the chain of certificates to ensure it comes from a trusted CA. It will of course check the revocation of that certificate, and any certificates in the chain above it. But what do you expect will occur if revocation checking fails? Such as being able to reach the revocation site, finding an expired CRL, a tampered CRL or an inactive OCSP Responder?

In my In-Depth class I use IE as an example of the principle that despite what a RFC may indicate SHOULD occur, applications are written at the discretion of the developer(s). Would you be surprised to learn that IE will ATTEMPT to check the revocation of the certificates for the TLS website, but if it encounters any errors, the default behavior is to NOT report an error to the user and just continue to load the website and show it as secure? Yup – that’s right, all an attacker would have to do it block your access to a CRL and IE will report the website as secure. The RFC states that revocation checking must succeed and if it doesn’t, you should assume the certificate is invalid until you can.

So why does IE do this? You can read more details in this old blog post at Microsoft – that surprisingly isn’t well publicized. It explains that Microsoft determined that possible connectivity issues may prevent IE from being able to reach revocation information so they decided to have it perform “soft” CRL checking. It will try to reach the CRL and if the CRL contains the serial number of the TLS certificate in question – it will report it as unsecure. However, if the CRL is expired, invalid or simply can’t be reached, no error message at all.

While this might be an acceptable (not in my opinion) option for home users who might be adversely affected by accidental certificate invalidation, I doubt most enterprises are willing to accept this risk. The surprising thing is that almost every organization I have worked with or trained, has never known that IE performs this “soft” CRL checking. They are often surprised that their browser has this default behavior – I was too, when I first found out.

Fortunately, this can be fixed through a Feature Control Key. Alright, let’s just call it what it is – a registry key!

There is a key to turn the feature on:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_WARN_ON_SEC_CERT_REV_FAILED]
“iexplore.exe”=dword:00000001

And a key to turn the feature off (return to the “soft” checking)

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_WARN_ON_SEC_CERT_REV_FAILED]
“iexplore.exe”=-

You can of course craft a Group Policy to push this out to your enterprise.

So let this be a lesson to make sure you make no assumptions about how your applications and systems are using and validating certificates. Trust but Verify I say! So what are you waiting for?