Working on refining our security policy for SSL – boy what you find out when you dig!

15 Jul 2009

SSL and TLS is the layer that provides most of the work when it comes to a secure connection. Most of our OpenCRM customers understand the need for a secure connection, but many will not, perhaps, fully appreciate what options are available to them. When it comes to other secure sites, I am sure they are very much in the dark.

In a secure connection the part that determines the type and strength of the security is the Cipher (encryption technique). There are many different Ciphers, including some that are notoriously poor, such as the Export-grade ciphers that hang around from the days that the US did not allow export of its security intellect.

AES, the Advanced Encryption Standard, is one of the more recent, and secure Ciphers, although its been around for a number of years, it is still relatively new, but has become the most popular algorithms used in symmetric key cryptography, which is used for the actual transmission of SSL data. This is the platinum service when it comes to encryption techniques. Many corporate clients and government bodies insist on this Cipher and will not accept anything less.

AES is very secure, in fact it complies with the FIPS (federal Information Processing Standard), there are no known ‘non-brute-force’ direct attacks against AES (there are a small number of attempted side channel attacks on the processing of AES, which are not applicable to SSL in general). As an example of the confidence in AES, the US government will use the 128bit cipher to transmit SECRET information, and 192bit or 256bit Ciphers to transmit TOP SECRET data.

How SSL works is really quite simple, and this is where it starts to get really interesting.

The Client software, such as your Browser, sends a list of Ciphers which it supports, the server then goes down the list of options, in the order that it is presented, until it finds a Cipher that the server has installed and can connect with. This means that the process is driven from the Client Browser side, working down the list until the handshake is set. The Server will just select the first matching Cipher and that way the most secure connection should be made.

This is fine in principle, until you start to dig a little deeper, and this is the bit that was news to me!!

One of the alternatives to AES is a Cipher called 128-bit RC4, which is quite common, but suffers from not being as secure. In fact its the RC4 Cipher that is used on WEP Wireless encryption, which is fairly poor.

Most decent websites will only allow secure connections with Ciphers that are recognised as being secure, but they will support multiple (less secure) Ciphers to cater for broken software or old technology clients.

What is interesting is seeing what happens by default if you have a number of Ciphers installed on a website, and you try and connect with different Browsers!

Here’s a cool website to check out your browser – you will get a report on screen showing how your browser is connecting by default, here a few results that I have collected through the web;

FireFox 3.0.5 on Windows XP and Vista – AES 256-bit
FireFox 3.01 on Mac OSX 1.5.5 – AES 256-bit
Safari 3.2.1 on Windows XP – RC4 128-bit
Safari 3.2.1 on Mac OSX 10.5.5 – AES 128-bit
Safari on iPhone 2.2/3.0 – AES 128-bit
Internet Explorer v7 on Windows XP – RC4 128-bit
Internet Explorer v7 on Windows Vista – AES 128-bit

Looking at this list you can see that the same Browser, Internet Explorer, on different operating systems, report different results.

So what becomes obvious is that your Operating system Cipher table defaults are different. If you are using the default libraries on XP you will be connecting with dependant applications (IE and Outlook) at a lower level. So, I guess you should be using FireFox or Opera (that’s another one that comes out well) as these use their own Cipher management.

I raise this for two reasons, a) I actually found this information and the subsequent research fascinating and something that is easily missed when you set up a secure connection, with the assumption that ‘secure is secure’ and nothing you can do about this (as standard) on your desktop, and also b) because some of our clients will not be aware of this limitation, and therefore, would benefit from a security overview session or at the least some advice from our support desk about how best to manage their systems.

One article helped with my research more than any and they made an ‘off topic’ comment, which again I found interesting. Skype use the AES 256-bit Cipher by default, so actually, for all of the industry bluster, its pretty secure (in terms of data transfer anyway).

So my suggestion, connect to your OpenCRM system with FireFox as your preferred browser, as this will then connect at the highest levels of security available, AES 256-bit, that’s TOP SECRET to you and I :0)