Who do you trust?

I trust a few people and organisations – my parents, some close friends and a handful of organisations such as EFF. Your personal circle of trust is probably not hugely dissimilar.

I wonder, have you heard of DigiNotar or Comodo before? Do you realise that you implicitly trust them and hundreds of other organisations every time you use your Internet web browser?

What are you trusting these organisations to do? You trust them to vouch for secure web sites that you visit. These 650 ‘trusted’ organisations are SSL Certificate Authorities (or CAs) and they are responsible for confirming that a given domain name and web site belongs to the legal entity named in the web server SSL certificate.

As a result of security weaknesses, the integrity of the Comodo and DigiNotar Certificate Authorities was breached in hacks which made news all around the world. Even the non-tech press realised the significance of these attacks.

The hacker responsible was able to generate a number of bogus web server SSL certificates, which were used by persons unknown to transparently intercept and spy on communications with popular web services such as Gmail, Skype and Facebook.

(Update: This article was written in 2011, before Edward Snowden’s revelations about NSA interception techniques. The paragraph above now has extra significance with regards to the persons unknown!)

This led me to question the role of certificate authorities and how fit for purpose the SSL protocol is in the modern Internet world of web applications.

The original SSL protocol specification was drafted in 1994 by Netscape engineer Kipp Hickman. In the section describing ‘Man In The Middle’ attacks the author simply says:

During the security connection handshake the server is required to provide a certificate that is signed by a certificate authority.

Any good secure protocol requires three elements: secrecy, integrity and authenticity. Apparently Hickman himself has admitted that authenticity was “thrown in at the end” of the SSL protocol specification. This weakness of SSL is a fundamental and critical flaw. This is the element where commercial interests, criminality and good old fashioned human error have all come into play.

In the early days of SSL, VeriSign was the lone certificate authority entrusted to verify that a web server belonged to a particular domain name and legal entity. The problem with a monopoly such as this is that without competition the CA can set an unreasonably high price for the service they provide. To stimulate competition more and more CAs were added to the trusted root certificate lists and over time we now find ourselves with literally hundreds of ‘trusted’ CAs.

So what makes these businesses trusted? Judging by some of the CAs that have bought their way onto the list – not a lot!

StartCom CA for example will issue free SSL certificates with only cursory validation. In their own words:

Class 1 Certificates provide modest assurances that the email originated from a sender with the specified email address or that the domain address belongs to the respective server address. These certificates provide no proof of the identity of the subscriber or of the organization.

Most Internet users naively assume that seeing https and the padlock icon is a guarantee that the identity of the web site owner has been verified and the web site is secure. Actually both assumptions are no longer true.

It is no longer necessary to go through strict vetting procedures to obtain a valid and trusted SSL certificate. With fake certificates having already been created via compromised CAs there is also no guarantee that your communications are safe from a man-in-the-middle attack.

Former Netscape Chief Scientist Dr Taher Elgamal is credited as being one of the co-authors of the original SSL specification. He too has voiced his concerns that a copycat attack against CAs could result in more rogue SSL certificates:

It could happen again. There’s no back-up plan, which is generally a bad security model. The problem of what to do when certificate issuers were compromised never came up when the original work was being done on SSL/TLS. Nobody asked the question of what to do if a certificate authority turns out to be bad. The problem was not so much with the technology as it was with the firms issuing the certificates.

There’s way too many of them.

But what of the Online Certificate Status Protocol (OCSP), which was specifically designed to protect us from rogue SSL certificates? Well that is unfortunately flawed too and can be bypassed using a simple protocol trick.

So are there any workable alternatives to SSL?

Moxie Marlinspike (the security researcher who found the OCSP flaw referenced above) has been giving it some serious thought. He was inspired by a concept called Perspectives which he has improved on and developed into Convergence – “An agile, distributed, and secure strategy for replacing Certificate Authorities“.

Convergence is still in its infancy and it’s not perfect, but with SSL now coming of age it could be a critical enabler for the future of secure communications.

I’m glad that someone who understands the weaknesses of SSL has proposed an alternative to CAs. Let’s hope that this effort gains some momentum in the industry and together we properly solve the issue of web server authenticity.

Security and The BEAST

The news of supposedly trusted certificate authorities DigiNotar (now bankrupt) and Comodo being penetrated by hackers was a severe blow to the long established SSL/TLS chain of trust security model.

Now there’s another serious web security vulnerability to be concerned about.

Security researchers Juliano Rizzo and Thai Duong have exploited a weakness in CBC (Cipher Block Chaining) based ciphersuites which they have used to create a proof of concept attack on SSL.

Their exploit is called BEAST (Browser Exploit Against SSL/TLS) and it demonstrates how to steal a web browser session cookie that is supposed to be protected by SSL. The implications of this are that your supposedly secure (i.e. HTTPS) web browser sessions can be hijacked by a third party.

How can we protect against this? Well since BEAST exploits CBC then web server administrators need to use a different cipher.

Google have switched to using the RC4 cipher on their web sites and Microsoft has issued an advisory recommending that you “prioritize the RC4 algorithm in server software in order to facilitate secure communication using RC4 instead of CBC“.

Sending email from an O2 Broadband connection

There are many options for sending email from an O2 Home Broadband connection:

  • If you have a static IP address (provided free with ‘The Works’ package or as a cost option in other packages) and you have access to a third party mail relay (e.g. SMTP2Go or AuthSMTP), you can connect directly to the external SMTP server on port 25
  • If you have a regular dynamic IP address then you can still connect to an external mail relay, but O2 blocks port 25 (SMTP) and so you will have to connect on port 587 (message submission)
  • Use the O2 Broadband mail relay – relay.o2broadband.co.uk – this will only accept mail from your broadband connection and will not work when outside of your home network
  • Use the O2 Mobile Data mail relay – smtp.o2.co.uk – you will need to authenticate yourself using your O2 portal username and password

If using smtp.o2.co.uk then you will also need to authenticate yourself using your O2 portal username and password. Note that even if using your own domain name your O2 username will also be made visible to the recipient in the mail headers, e.g.

Received: from yourhost.example.com by mail.o2.co.uk ( (authenticated as yourlogin@o2.co.uk)

O2’s mail servers do not support SSL/TLS and so you will need to specify an insecure connection when configuring your mail client.

In the Windows Mail client go into the mail account properties and under the Outgoing Mail Server settings in the Servers tab tick the box next to ‘Outgoing Mail Server: My server requires authentication’. Go into these settings, fill in the account name and password with your O2 portal credentials and make sure that ‘Log on using Secure Password Authentication’ is NOT checked. In Advanced settings make sure that ‘This server requires a secure connection (SSL) is NOT checked.

For Unix users I have provided instructions for configuring exim4 to use an external smarthost in a separate post.