Today Microsoft released a security advisory (961509) regarding collisions in MD5 hashes on certificates. This specific problem affects the entire industry and is not a Microsoft specific vulnerability. Serious weaknesses in MD5 have been known for many years now; it is because of these weaknesses that MD5 is banned in new code under the Microsoft Security Development Lifecycle (SDL). Software developers are urged to migrate away from using MD4, MD5 and even SHA1 and use SHA-256 and later instead for hashing, signatures and message authentication codes (see slide 22 for more information http://download.microsoft.com/download/8/4/7/8471a3cb-e4bf-442a-bba4-c0c907d598c5/Michael%20Howard%20SDL%20Development%20Practices.ppsx)
The most common type of certificates that Certificate Authorities (CAs) will issue are for three main purposes:
In this context, we believe that the most likely attack scenario will through SSL/TLS (though we have not seen any attacks at this time.) Thus, common web browsers are similarly exposed to this problem since HTTPS uses SSL/TLS to establish the secure connection.
Thus the purpose of this blog post is to explain this problem in more detail as well as highlight mitigations and workarounds when using Internet Explorer.
Lastly, we should note that certificates hashed with SHA1 are not affected by this problem.
Summary of the problem
An MD5 hash collision allows a malicious user to potentially generate a rogue certificate derived from a valid one. This user can then impersonate a valid site or person since both certificates look legitimate because the certificate hashes are the same. An attacker will have to lure a user to initiate an SSL/TLS connection, then the certificate will be validated by the client and it will seem valid. Thus, the user will think that it is establishing a safe connection with site or person when in fact it is connecting with the attacker.
Although any certificate hashed with MD5 and then signed can potentially be manipulated we have not seen any active attacks.
Mitigations & Workarounds
Green filled address bar (IE7 & IE8)
Extended Validation certificates (http://www.cabforum.org/EV_Certificate_Guidelines.pdf) are required to use SHA1 (instead of MD5) Thus, these certificates are not affected by this problem. Internet Explorer 7 and later take advantage of EV certificates by highlighting the address bar in green. See http://blogs.msdn.com/ie/archive/2006/11/07/improving-ssl-extended-validation-ev-ssl-certificates-coming-in-january.aspx for more information. Below is such an example:
In short, if Internet Explorer 7 address bar is highlighted in green then there is no risk against this attack.
Certificate revocation in IE7 & IE8 & OCSP configuration
Certificate revocation allows a Certificate Authority to revoke a specific certificate, after which it is no longer accepted as valid by the user’s browser. While it does not fully help prevent the attack, it improves the ability a certificate authority has to respond to them by allowing them to disable fraudulent certificates.
Certificate revocation is enabled by default for Internet Explorer 7 and later (running on Vista & above) since Online Certificate Status Protocol (OCSP) is used to confirm whether a certificate is valid or not. Thus, in the event that a malicious certificate is being actively used then a Certificate Authority can revoke it and Internet Explorer will automatically block the web-site visited.
Below are the steps needed to configure an OCSP.
Steps to Configure Custom OCSP Responder Location Locally on Vista SP1 and Windows Server 2008:
Steps to Configure Custom OCSP from Group Policy
Certificate revocation on IE6
Certificate revocation checking is disabled by default on Internet Explorer 6, as it requires the download of a Certificate Revocation List (CRL) to validate whether a certificate is still marked as valid. On low bandwidth connections, such as dial-up, this may increase latency.
Certificate revocation for Internet Explorer 6 can be enabled following the below steps:
See below link for more information:
Reviewing the certificate
Another alternative to verify whether the certificate is using MD5 is to look at the certificate details. It is important to note that the certificate itself and the entire chain (the Certification Path), excluding the root, needs to be reviewed to assess whether a certificate hashed with MD5 has been used. Below are the steps on how to do this in Internet Explorer 7.
Caveat: If the rogue certificate has misleading information about the CRL then web browsers might not be able to identify the certificate as revoked. In corporate PKI deployments, we recommend configuring a specific OCSP responder in the Windows OCSP configuration. This will allow organizations to revoke certificates that have been fraudulently signed and modified to no longer carry a correct validation location.
We would like to thank the engineers who helped build the above guidance:
Finally, the link to the Microsoft Security Response Center (MSRC) blog, which discusses this advisory is: http://blogs.technet.com/msrc/archive/2008/12/30/information-on-microsoft-security-advisory-961509.aspx
Update 12/31/08: "Reviewing the certificate" section updated in resposne to e-mail to switech AT microsoft.com.
Damian Hasse, MSRC Engineering Blogger
Posting is provided "AS IS" with no warranties, and confers no rights.