Internet identity broken.. again

James Lyne
There have been a flurry of attacks on SSL, the technology that by and large provides transport security and identity validation when working on the web (when you access your bank for example you will be using SSL).

At Blackhat/Defcon this weekend several new vulnerabilities came to light: a very scalable denial of service, a bypass for mixed SSL/normal content pages and an exploit of the trust model using null characters in certificates.

I could spend pages detailing each of these and their implications, but I would like to pick out the null character problem specifically. This vulnerability, which has caught the attention of the media, allows an attacker to get a certificate from a Certificate Authority (CA) that will be accepted by the browser for a site they do not own.

The implications of this are that the attacker can pretend to be any other website and engage in secure communications (for example, your bank!).

Essentially, it works like this:

  1. The bad guy requests a certificate for from a global certificate authority who issues certificates (such as Verisign). (The represents a null character).
  2. The CA sends an email to the owner of to validate that the certificate should be issued and to validate that he actually owns the site he requested (if you could just request a certificate for and pretend to be them all this SSL stuff wouldn’t be very useful!)
  3. The certificate is issued and the attacker loads it for a man in the middle or redirection attack (essentially, pretending to be
  4. Users hit the bad guy’s spoofed site and the browser receives the certificate.
  5. Some browsers read the first portion of the certificate only, seeing and that it is signed by a CA. The user is given access to the site and no warning is ever generated – the browser thinks that this page is and it has the correct cryptographic identity.

The really nasty variant of this is when a user requests * as this would give a certificate that works with literally any website on the internet. A very scary prospect indeed.

So what can you do?

  • Not all browsers are vulnerable to the attack (Firefox 3.5, for example, does not have the issue). Make sure you validate that your deployed browser is not vulnerable and deploy patches as soon as possible!
  • You are in luck if you are running a Sophos web security appliance. We are releasing an update this week which automatically detects these malformed certificates and blocks them before they get anywhere near the user or the browser.
  • Certificate authorities are of course scrambling around trying to remove this logic fault, however it is not going to fix the certificates that have already been issued (and I have yet to hear comment on how many that might be!). So, the only real short term fix is for clients to ensure they appropriately parse certificates to validate identity.
  • Educate your users! Most users still think that the padlock equates to absolute security (and some don’t even notice that!). Ensure that they are looking out for suspicious behaviour and have the normal protection mechanisms should the attacker decide to drop malicious code.

Broadly speaking though, whilst these vulnerabilities keep popping up in SSL there is a greater and far simpler problem with this infrastructure.

SSL relies on validation of the certificate according to a CA which imparts a level of trust to the certificate allowing (assuming other attributes like address and expiry date are correct) the user to supposedly assume a level of trust. Self generated certificates not signed by a CA can also used for internal testing or pure transport encryption. These self generated certificates will generate warnings in the client about the identity of the site in question.

Many attacks on SSL infrastructure work using the principle of man in the middle, where the attacker sits in between the end user and the server and is able to manipulate communications.

In this scenario a bad certificate is not signed and generates an alert to the end user questioning the security posture and legitimacy of the site.

The problem is that like UAC in Vista these alerts pop up and users just click ignore, irrespective of the information contained in the message! An ‘elegant’ hack is not required when most users will simply click OK anyway. Browsers have tried to improve this logic (Firefox 3.5, for example, has a far more bold rejection) but it seems that user frustration rises and the behaviour persists – they access the page anyway.

Clearly, we as security professionals need to do better at educating users and I believe there is significant room for improvement in the alerting model provided by browsers.

In summary, the concept of internet identity is badly broken and has been for a while irrespective of these new rather effective vulnerabilities.

As we continue to move services in the cloud and all operate in a far more connected world we will have to develop far more robust methods – the theory of X.509 was good, the end community implementation just isn’t working the way we need.