Why offload SSL/TLS from Application Servers?

As more and more sensitive data traverses the Internet, it is important to secure this information. Per RFC 5246, securing network communications via SSL/TLS "allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery." Accordingly, many websites and applications in present day use SSL/TLS as a method to secure information that traverses the Internet. While using cryptography is a great way to secure information traversing insecure networks, the encryption and decryption of this data is computationally expensive. At scale, the cryptography traditionally performed on one's application servers can consume resources otherwise used for processing application data and deter performance of the application.

One methodology widely used in the industry today to increase performance of secure applications is to use SSL Offloading. Here, specialized network devices act as the SSL/TLS conversation's end-point by performing the handshakes and cryptography associated with an end-user's SSL session. Next, the request is proxied to internal networks that run the application. Historically, RSA cryptography has been used to secure these SSL/TLS sessions. However, minimum key-lengths required to generate valid certificates have been regularly increasing due to growth in computing power and other systemic issues found (e.g. pseudo-random number generator vulnerabilities) that may allow secure data to be compromised.

The Certification Authority/Browser Forum requires that all certificates issued after January 1, 2014 have at least a 2048-bit RSA key length. More detail can be found Section 3 of Appendix A of CA/B's Baseline Requirements Version 1.1.9. Such key lengths require expensive specialized hardware or a significantly higher number of CPUs to quickly and efficiently decrypt SSL/TLS traffic. Practically speaking, an application server currently processing 1000 secure connections per second with a 1024-bit RSA key would only be able to accept approximately 180 connections per second with the same computational power and a 2048-bit RSA key [1].
 

Why ECC + PFS?

With next-generation Elliptical Curve Cryptography (ECC) and Perfect Forward Secrecy (PFS) Secure Sockets Layer (SSL) technology, more secure encryption can be achieved with less computation power compared to traditional RSA arithmetic [2]. This is due to the significant increase of cryptographic strength per key-bit when utilizing the more complex ECC algorithm [3]. When using ECC curves, the CA/B Forum requires only a minimum of 256 bit ECC public keys. Cryptographically speaking, this translates to the equivalent security of:
 

ECC Curve

Equivalent RSA key

Notes

secp256r1 (NIST P-256)

 3,072-bit

Also known as prime256v1

secp384r1 (NIST P-384)

 7,680-bit

 

secp521r1 (NIST P-521)

 15,360-bit

 


Perfect Forward Secrecy increases the integrity of secure communications. It ensures that the encryption of a given session is unique to that session. Should a private key be compromised in the future for any reason, only one session (rather than, say, an entire year's history of communications) can be successfully decrypted. PFS technology complements the security gains of ECC cryptography and helps provide a much more secure experience for end-users over that of RSA cryptography. With the combination of ECC and PFS technologies, an overall more secure experience can be gained with less computation than RSA based cryptography solutions.

By implementing cryptography with Elliptical Curve Cryptography versus traditional RSA PKI, direct CapEx and OpEx savings can be appreciated by:

  • Limiting cryptography processing power needed
  • Reducing communications channel overhead
  • Increasing power efficiency
     

Advantage of LineRate

In regard to cryptography, the software based LineRate solution is an industry-leading platform. SSL Offloading on LineRate includes software optimizations in OpenSSL for modern Intel x86 architectures. Many of these optimizations can increase performance of ECC cryptography up to 600% versus standard CPU computation [4].

Effectively, when this cryptography performance is combined with the highly optimized network stack of LineRate, the user of a LineRate SSL Offload implementation will be providing their end-users with the most cutting edge SSL Offload technology available on the market. Specifically, LineRate provides the following advantages over existing software-based or hardware-based SSL/TLS offload solutions:

  • Industry-leading Elliptic Curve Cryptography (ECC) performance
  • Optimized cost of systems: extremely competitive cost for each SSL connection per second
  • Up to 25,000 new ECC-based SSL sessions per second achieved versus only about 8,000 new RSA-based SSL sessions per second on the same commodity Intel CPU [5]

Additional features of the LineRate System are also at one's fingertips. Some of these powerful features include:

  • High-performance connectivity through commodity hardware or virtual machines
  • Customizable Node.js scripting engine for data-plane traffic
  • Session-based persistence for HTTP traffic
  • APIs for zlib compression
  • High Availability (HA) 

 

Stay Tuned!

Next week a demonstration on how to implement SSL with ECC+PFS on LineRate will make a debut on DevCentral. The article will detail the entire configuration process from creating ECC certificates to configuring the LineRate system to act as an SSL/TLS end-point for clients (i.e. SSL Offload). In the meantime, take some time to learn more about Elliptic Curve Cryptography and the advantages it brings to your organization. If you are ready to learn more about LineRate or give it a test run in your organization, feel free to visit the links below:

Ready to try LineRate? Visit https://linerate.f5.com/try
Want to learn more about LineRate? Visit https://linerate.f5.com/learn

 

In case you missed any content, or would like to reference it again, here are the articles related to implementing SSL Offload with ECC and PFS on LineRate: 


Qr code

References

[1] Gail Ferreira and Ken Salchow. Minimize the Impact of 2048-bit keys in SSL processing.

[2] Intel Integrated Performance Primitives Reference Manual: Elliptic Curve Cryptography Functions

[3] National Security Agency. The Case for Elliptic Curve Cryptography

[4] Krzysztof Jankowski, Pierre Laurent, and Aidan O’Mahony. Intel Polynomial Multiplication Instruction and its Usage for Elliptic Curve Cryptography

[5] Lori MacVittie. Stronger Keys and Faster Security with ECC