The State of eCommerce Security – Web Browser Safety

This month, we learned about the BREACH attack. A new exploit that uses flaws in TLS compression to decipher small pieces of encrypted data. It is an updated version of the CRIME attack which also attacked TLS compression. This is a good example of attacks only getting better as time goes forward. I felt that with this new flurry of news about security breaches in the news, that I would give you all a brief history on the state of cipher suites in eCommerce. 

The Transport Layer Security (TLS) stack has been under siege since its inception in 1999.

1.       Padding Oracle Attack – 2002 – Researchers find a vulnerability in the way that TLS fills in space when data doesn’t take up an entire packet. It is entirely theoretical and cannot be demonstrated as working.

2.       BEAST Attack – 2011 – Researchers find a serious vulnerability in Cipher Block Chaining (CBC) mode ciphers in TLS.

3.       CRIME Attack – 2012 – Researchers find a vulnerability in TLS compression that can reveal data.

4.       BREACH Attack – 2013 – Researchers improve on the CRIME attack and have a more sophisticated attack against TLS compression.

5.       LUCKY13 Attack – 2013 – Researchers improve on the 2002 Padding Oracle Attack, and are able to recover encrypted data from CBC mode ciphers in a lab environment (some of the specifics make it unrealistic in the real world).

6.       RC4 Attack – 2013 – Researchers dramatically improve attacks against the widely-used RC4 cipher.

7.       TLS Truncation Attack – 2013 – Researchers find a way to (as a middleman) intercept a “sign off” request for a client, which can then be compromised when the unassuming person leaves the still-logged-in PC.

So, armed with this list, we can also take a look at how TLS has progressed to fix the things in these vulnerabilities, and the story changes a bit.

1.       2006 – TLS 1.1 is released, nullifying the Padding Oracle Attack, Beast, and Lucky13.

2.       2008 – TLS 1.2 is released, revising to even higher strength cipher suites and fixes for theoretical attacks.

Compression in TLS can be disabled easily, rendering those exploits useless.

RC4 can simply be disabled, mitigating any breaches against it (they are coming, attacks against RC4 are rapidly approaching strengths in which we should be concerned about the security of RC4).

This makes the picture for security look a lot better, right? Well it would be, if it wasn't for browser support. All of the major browsers have been dragging their feet on adoption of TLS 1.1 and TLS 1.2. This leaves web hosts with very limited choices: Either allow potentially unsafe ciphers to be used, or block out users with unsupported browsers.

TLS Support by browser as of 8/3/2013:

As you can see from this graphic, the current version of Firefox, Internet Explorer, and Safari 6 on OSX, support the same cryptography as Netscape Navigator. If you are too young to remember Netscape, it ended development in 2002.

So with a huge swath of the browser market not supporting TLS 1.1 and TLS 1.2. A server admin can’t simply shut off TLS 1.0. You also can’t simply shut off CBC mode ciphers, because they are much stronger in TLS 1.1 and 1.2 than RC4. There are other ciphers like AES in Galois Counter Mode, but no browser currently supports GCM mode ciphers.

It is further complicated by conflicting advice from experts. Pressured to make “cookie cutter” solutions for admins to follow, Qualys has urged people to adopt RC4 over CBC mode ciphers. The reasoning is that the flaws in RC4 are seen as not as bad as they are with CBC mode ciphers in TLS 1.0. The other, more extreme approach is to disable TLS1.0 entirely, which means that you are shutting out a huge number of people from your website because they are running unsafe browsers.

Neither solution seems elegant.

My approach is a compromise between the two. For VikingVPN I have left TLS 1.0 enabled, and left the RC4 cipher enabled, but I am putting a warning on the front page to let users know that their browser session may not be secure if they are using a browser with security that is literally 7+ years behind. The browser companies have been very nonchalant about security, and it is time for them to lose market share if they haven't kept up. I think that web hosts need to at least take steps to secure connections for knowledgeable users, but also step-in and let people know when they are using insecure browsers rather than block them out entirely from the site. This ensures that users that are on browsers that support TLS 1.1 and TLS 1.2 have known secure cipher suites enabled. If I took the Qualys approach, no one would be secure as they would all default to RC4 ciphers which are problematic at best, and wholly insecure at worst.

Here is my recommendation: Unless you are using Internet Explorer 11 Beta in Windows 8.1 Beta, Safari 7 in OSX, or Safari on iOS, get the latest version of Google Chrome Beta here. If you are really attached to your Internet Explorer, you can modify some settings to enable TLS 1.2 in IE9 and IE10There is also a beta version of Firefox with TLS 1.2 support (if you manually enable it) here.

To manually enable TLS 1.2 in the latest Firefox 24 beta build, type about:config in the address bar. Look for the line “security.tls.version.max” double click it, and set it to 3. This gives you partial TLS 1.2 support.

< last
next >