Zscaler Data Protection Recognized as a 2023 Product of the Year by CRN

Zscaler Blog

Get the latest Zscaler blog updates in your inbox

Security Research

Breaking Down Broken SSL

January 02, 2009 - 4 min read

On December 30, 2008 at the 25th Chaos Communication Congress (CCC) in Berlin, seven researchers presented a talk entitled 'MD5 Considered Harmful Today: Creating a Rogue CA Certificate'. In essence, they made the theoretical practical by building on recent research which detailed how chosen-prefix collisions for MD5 could be used to create two x.509 certificates with identical signatures despite having different content. The CCC presentation has taken this work a step further to actually produce an intermediate CA certificate signed by a trusted root CA. This certificate can then be used sign any website certificate. A website certificate created by the team can be seen in the image below. Note that Internet Explorer in this case considers the certificate to be legitimate.

As you can imagine, the ability to create fake SSL certificates is a phisher's dream come true. An attacker possessing such a rogue certificate could produce fake SSL certificates for phishing sites which would be indistinguishable from their legitimate counterparts. However, before we conclude that the sky is falling it's important to understand that while such attacks have now been proven to be possible, it would still be difficult to an attacker to successfully mount a successful attack.

Ingredients For a Successful Attack

1.) Knowledge - While the CCC researchers have published a detailed paper to discuss their findings, they will thankfully "for the time being not release the full details of how [they] have been able to obtain the rogue Certification Authority certificate". While their research is based on past work that is now public, they confess that the "publicly known techniques have been improved at crucial points". In short - simply reading their paper/slides will not be enough to conduct a successful attack, additional research would be required. That said, you can bet that the race is now on for the bad guys.

2.) Computing Power - In order to calculate the MD5 hash collisions to produce the rogue CA certificate, the team employed a cluster of 200 PlayStation 3 consoles. While such technology is readily available, there is a real cost associated with acquiring the necessary computing power to replicate their work.

3.) Traffic Redirection - This is the biggie. Producing a rogue SSL certificate for say bankofamerica.com is of little value if it is not hosted at bankofamerica.com. Hosting the certificate at any other domain will result in a warning message from any visiting web browser indicating that the certificate does not match the domain name. The necessary traffic redirection is realistic on a LAN segment, but would be very difficult to accomplish on the Internet as a whole. Attacks such as Dan Kaminsky's DNS cache poisioning attack would provide the critical missing piece of the puzzle but fortunately this vulnerability has aged to the point where it has primarily been addressed.

Why This Was Possible

The CCC researchers largely credit the work of Marc Stevens , Arjen Lenstra and Benne de Weger on chosen-prefix collisions for MD5 which was released in 2007. However, their success was also made easier by less than perfect processes at a number of Certificate Authorities. Certificates do not have to be signed using MD5. In fact, MD5 was shown to be vulnerable to attack as early as 2004 and yet a number CAs still employ MD5 for certificate signatures. The worst offender turned out to be RapidSSL (owned by VeriSign), which was responsible for 97% of the MD5 signed certificates that the researchers looked at. The team also faced other challenges such as predicting the validity period and serial numbers of the certificates issued by the CA that was being targeted. This was made much easier by the fact that certain CAs are apparently using sequential serial numbers.

What Needs To Be Done

So, what can you do to protect your users from falling victim to phishing attacks on sites that may have rogue certificates? Unfortunately, there isn't a good answer to that question. If someone were to successfully create a rogue certificate it would be difficult evn with manual inspection to identify it as rogue. The researchers took the approach of developing an intermediate CA certificate which could then be used to sign any website certificate, therefore you could identify/block any web certificates signed by an intermediate CA which is not specifically trusted but that could also block some legitimate sites. It should be noted that it is not enough to block sites with MD5 signed certificates (unless MD5 was not used for signing at any point in the chain of trust). While MD5 collisions were used to develop the rogue CA certificate, once it is developed, MD5 does not need to be used for signing subsequent website certificates.

The fix really lies with the CAs. The fact that some have continued to use MD5 instead of a more secure alternative such as SHA-2 for signing certificates some four years after real weaknesses in the algorithm were demonstrated, is inexcusable. They also need to inject randomness into the signature generation process, most notably in the serial number field. Hopefully this research will force CAs to quickly phase out the use of MD5 for developing certificate signatures and improve their procedures overall.

Happy New Year!

- michael

form submtited
Thank you for reading

Was this post useful?

Explore more Zscaler blogs

A cyber criminal shopping for malware
Agniane Stealer: Dark Web’s Crypto Threat
Read Post
Business people walking through a city
The Impact of the SEC’s New Cybersecurity Policies
Read Post
Digital cloud illuminated in blue
Security Advisory: Remote Code Execution Vulnerability (CVE-2023-3519)
Read Post
The TOITOIN Trojan: Analyzing a New Multi-Stage Attack Targeting LATAM Region
Read Post
01 / 02
dots pattern

Get the latest Zscaler blog updates in your inbox

By submitting the form, you are agreeing to our privacy policy.