Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Will SSL Collapse Under its Own Weight?

Will SSL Collapse Under its Own Weight?

This item in japanese

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?

Rate this Article