In December 2008, a group of computer security researchers attending a security conference in Berlin gave a practical demonstration of a serious security vulnerability related to the public key infrastructure (PKI) that allows for secure web browsing used for online banking, e-commerce and other sensitive transactions. In short, they were able to show the possibility of mimicking any website on the internet.
The vulnerability is tied to a cryptographic weakness related to the MD5 cryptographic hash function. The practical effects to web security based on this weakness is serious, but can be corrected by replacing vulnerable server certificates with ones not yet known to be vulnerable to attack.
In January 2009, Govcert.nl published a very useful fact sheet on these vulnerabilities that provides both a basic primer on the problem and the pros and cons of the available remedies. Although there is no doubt that sites using MD5 hashes need to take action, these guidelines are intended to help IT decision-makers more easily choose the best course of action available for their individual circumstances. [The following is based upon Govcert.nl Factsheet FS-2009-01, which is available from their website, and subject to a Creative Commons by-sa 3.0 license.]
Vulnerabilities in the Internet PKI caused by the use of MD5
On 30 December 2008 a group of researchers at the ‘Chaos Communication Congress’, an annual security conference held in Berlin, gave a practical demonstration that the ‘Public Key Infrastructure’ (PKI) on the internet has some serious weak spots.They demonstrated that they had been successful in creating a rogue certificate that was trusted by all common browsers.
An overview of the facts:
Researchers have created a rogue certificate that can be used to impersonate any website in the world.
- This rogue certificate is automatically trusted by all the common browsers.
- The researchers achieved this by making use of weaknesses in MD5, a cryptographic hash function.
- Even though the weaknesses of MD5 have been known for many years, it is still used to sign certificates on the internet.
- If you still make use of certificates that are signed using MD5, then you need to replace it as soon as possible.
In this factsheet you can read a short explanation of the research, the risks in the short term and the actions that need to be undertaken both by yourself and by other concerned parties. We conclude this factsheet with two paragraphs with background information on digital signatures, hashes, collisions and the shelf life of cryptography in general.
The research in brief
This research has an impact on the use of certificates to set up secure connections between a browser and a website. This concerns an ‘HTTPS’ or ‘SSL/TLS’ connection. Such a connection can be recognised within browsers by means of a padlock or in some cases by a coloured address bar.
The research demonstrates that when a certificate has been signed (or appears to have been signed) by a competent authority (a Certificate Authority or CA for short), this no longer offers any guarantee that this certificate was also verified by this authority. This means that there is no longer any guarantee that the certificate actually belongs to the correct party. In other words: in the past you had a large degree of certainty with a secure connection that you were dealing with the right website (after checking the certificate). Now it has been demonstrated that this security can be compromised by a practical attack.
Certificates and secure connections
A certificate is the basis of two functionalities of a secure connection. These functionalities are most of all important for applications where personal or financial data are transmitted to another party, for example in the case of telebanking, egovernment services and online shopping.
- The encryption of data exchanged between the browser and the website. The result is that data can no longer be read by third parties.
- The possibility of monitoring whether a connection has really been made to the correct website.
The research to which we refer in this factsheet has an impact on the second function of a certificate.
Because there are still CAs that sign certificates with MD5, an obsolete cryptographic method, the researchers succeeded in creating a rogue certificate that appeared to have been signed by an official Certificate Authority (a root CA). As a result this rogue certificate is automatically trusted by all common browsers. What is even worse is that the rogue certificate itself can act as a Certificate Authority.
As a result, the researchers are in a position to create and sign a certificate themselves for any random web server in the world, which cannot be distinguished from a real one and which is trusted automatically. They can therefore impersonate any random other party without the visitor to a website being able to discover this on the basis of the certificate.
What are the risks in the short term?
The researchers admit themselves that it is unlikely that another person is going to be able to implement such an attack on the internet PKI in the short term. GOVCERT.NL has also not detected any attacks at the time of writing and more or less discounts that there are already rogue certificates in circulation at this time.
In order to carry out such an attack one needs specialised knowledge of the weaknesses in MD5, the obsolete cryptographic method still used by some CAs for signing certificates. In addition, the researchers themselves developed methods to create a rogue certificate in a short time. They believe that the CAs in question that still
make use of obsolete digital signatures will have enough time to move over to new methods.
In conclusion, the researchers have taken some measures to prevent the certificate they have created from being misused. The researchers have nonetheless made it known that they will eventually publish their methods, probably in a few months.
If it was not already clear following the previously publicised attacks in 2005 and 2007, there is not the slightest doubt now that it is irresponsible to continue to use MD5.
Protection against vulnerability and the actions you can undertake yourself
The researchers demonstrated with their research that the internet PKI contains weak spots because some CAs still make use of obsolete means of creating a digital signature. As a consequence the entire PKI is at risk, not just those persons who have dealings with the CAs in question. The following analogy will clarify this to a certain extent: if it turned out that it was very easy to obtain a real passport in a certain municipality in the Netherlands under false pretences, then that would be a problem not only for the residents of that one municipality but would also undermine confidence in the value of every passport for everyone who came into contact with passports.
The foregoing makes it clear that individual end users and owners of certificates can do very little to protect themselves against this vulnerability, let alone solving these. In an ideal situation the following would now happen:
- Every CA that still makes use of MD5 would stop doing so as quickly as possible and would migrate to a better hash function.
- Everyone who still has a certificate that has been signed with MD5 will replace this as soon as possible (see also: ‘Replace MD5 … but with what?’ on the following page).
- If the above two requirements are met (or that much earlier as is considered necessary), the browser vendors can withdraw support for MD5.
The most important parties in the above process are the CAs and the browser vendors. CAs bear a responsibility to make use of sensible cryptographic methods on the basis of their task as a trusted organisation that is permitted to sign certificates within a PKI. It is necessary to evaluate on a regular basis whether a cryptographic method is (still) reliable. It is the case that cryptographic methods that are reliable now may not be reliable for various reasons at a later time.
Browser vendors can exercise a great deal of indirect influence on CAs, because they determine which certificates—and therefore also the type of certificates—they include and trust in their browsers as standard. In this way they can serve as an extra motivation. If browser makers stop supporting MD5 (the weak hash function), then this would have immediate consequences for the certificates signed using MD5 that are still in circulation. These will stop working or generate warning messages, depending on the choices made by the browser vendors.
All this does not mean that you should not undertake a number of actions yourself:
- As an end user there is almost nothing you can do to reduce the risks of this proven threat. At this time there are still so many certificates with a MD5 signature in circulation that rejecting such certificates completely is not really a practical solution. There is an extension in circulation for Firefox5 that alerts the user to signatures based on MD5, but in practice this normally generates false positives. This is only an option for home users with expert knowledge.
- It is important within organisations to keep track of which and what type of certificates are in use, even if you have your own internal PKI with a root certificate. This includes certificates from your official websites, your internal websites, client certificates and other solutions that make use of SSL certificates, such as SSL VPNs.
- If you are still signing certificates internally on the basis of MD5 then make plans to phase this out. If you make use of certificates that are signed on the basis of MD5 then you need to replace these as soon as possible with certificates signed on the basis of a more recent algorithm. You can read more in the following paragraph about your options.
Replace MD5 … but with what?
The researchers’ motivation in publishing this research was to demonstrate that it has for a long time been irresponsible to use MD5 to sign certificates and they have been very successful in this. You therefore need to migrate now, but the question is: “To what, if MD5 is no longer satisfactory?â€
The successor to MD5 is SHA-1, but an even newer variant has been available for some time, namely SHA-2 (a collective name for SHA-224, SHA-256, SHA-384 and SHA-512). It has also been demonstrated that SHA-1 has some weak spots and it is expected that SHA-1 will in the not too distant future disappear as a result of practical attacks. The US National Institute of Standards and Technology (NIST) goes even further. It requires American government organisations to abandon SHA-1 and move over to a SHA-2-variant before the end of 2010.
You have two options at the moment:
- Transition to SHA-1. This is the easiest option. SHA-1 is supported by practically all CAs and all software. It is therefore relatively easy and cheap to make the transition. The disadvantage of this option is that SHA-1 already includes known vulnerabilities. Although this is not yet a practical threat, the strength of SHA-1 may soon come under pressure. If this is the case then it will be necessary to make a new transition, which will involve fresh costs.
- Transition to SHA-2. This option is less simple. Support for SHA-2 is far from being a matter of course for all CAs and all software. Before you migrate to SHA-2 you will need to find out if you are also going to have to upgrade your software. This of course entails additional costs. Moreover, the use of such a certificate can also create a problem for some visitors to your website if their browser does not support SHA-2. There is also an advantage to migrating to SHA-2. It is by far the most future-proof option at this time because SHA-2 is expected to last another ten years before any practical attacks will be possible.
[The original factsheet was published by Govcert.nl and is available in PDF format from their website.]