Will SSL Collapse Under its Own Weight?

Posted by Jean-Jacques Dubray on Feb 02, 2011

Sections

Architecture & Design,

Development

Topics

Security ,

Architecture ,

SSL

Share |

RELATED Research

SSL (or more exactly TLS) has established itself as one of the keystones of the Web. Hardly any Web-based business activty would be impossible without it. Because of that status, it is regularly attacked. Lorie MacVittie dispells the myth that SSL is not computationally expensive in her latest post, especially in the light of the NIST guidelines being adopted by the US government starting this month.

The way in which SSL is used – the ciphers, the certificate key lengths, the scale – has a profound impact on whether or not “computationally expensive” is an accurate statement or not. And as usual, it’s not just about speed – it’s also about the costs associated with achieving that performance. It’s about efficiency, and leveraging resources in a way that enables scalability.

...

While NIST is not a standards body can require compliance or else, they can and do force government and military compliance and have shown their influence with commercial certificate authorities. All commercial certificate authorities now issue only 2048-bit keys. This increase has a huge impact on the capacity of a server to process SSL and renders completely inaccurate the statement that SSL is not computationally expensive anymore. A typical server that could support 1500 TPS using 1024-bit keys will only support 1/5 of that (around 300 TPS) when supporting modern best practices, i.e. 2048-bit keys.

NIST recommends ephemeral Diffie-Hellman - not RSA - for key exchange, and per TLS 1.0 specification, AES or 3DES-EDE-CBC, not RC4. These ciphers are much less “easy” than RC4 and they are also more computationally intense. Lori also adds that this is not the only issue to consider when architecting an SSL based system:

• Certificate Management: the more servers you have, the more certificates you need to deploy. The costs associated with management of those certificates – especially in dynamic environments – continues to rise and the possibility of missing an expiring certificate increase with the number of servers on which certificates are deployed.
• Certificate/Security protection : the sensitive nature of keys and certificates and regulatory compliance issues may require hardware-based storage and management of those keys regardless of where they are deployed
• Loss of Visibility/Security/Agility: Encrypted traffic cannot be evaluated or scanned threats or routed based on content by any upstream device.

Not to mention the difficulty of using SSL in virtualized environments.

She warns that a purely technical approach to the deployment of SSL could severely impact the ability of an organization to support and align itself with the business.

While SSL is now deployed in areas that were once unimaginable, are we about to see major changes in Web protocol security and a segmentation by security levels which could impact interoperability?

1. Back to top

   Is it 1994 again?

   by Booker Bense

   This article seems incredibly naive and provides no real alternatives. Public Key like Democracy is the worst security system, it's just better than all the others that have been tried.

   Reply

2. Back to top

   Business is not cheap

   by Francois Ward

   Having a brick and mortar store is a lot more expensive than getting the hardware to do SSL.
   
   As the web gets more and more volatile and business critical, you can't just SSL the login page or the shopping cart: the entire session (on security critical sites of course. Your blog probably doesn't need it) starts needing to to be encrypted.
   
   Get the hardware, even if it means dedicated appliances, and just do it. Yeah, its not free, but doing business isn't cheap. Thats how it worked hundreds of years ago, its how it works today.

   Reply

3. Back to top

   Confusing article

   by Stefan Wenig

   The article complains that every last image needs to be encrypted, but what does that have to do with 1024/2048 keys? Those are PKI keys, only used for handshakes. User data is encrypted symmetrically, using much shorter keys.
   
   Am I getting this wrong, or is that article just mixing up symmetric and assymetric key lengths?

   Reply

4. Back to top

   Re: Confusing article

   by Jean-Jacques Dubray

   Symmetric encryption algorithms are indeed used in cipher suites to provide confidentiality. RC4 is a stream cipher that uses a variable length key of anywhere between 8 and 2048 bits long.

   Reply

5. Back to top

   If only there was a vendor to save us

   by Michael Neale

   One that provided proprietary hardware to do the magical work for a problem we didn't realize we had. Save us !

   Reply

6. Back to top

   Re: Confusing article

   by Stefan Wenig

   If this explains the relationship between the 1024/2048/4096 bit table and the computational load after the handshake (which the article seems to imply), I fail to see it. What's TPS anyway? Do transactions include a handshake? What was measured, and how? There's a lot of talk in that article, but only these numbers to support it, which are not explained.

   Reply