Encryption Curveballs: Top 10 Things to Know Before Enabling ECC Ciphers

Over the past two years, everyone has become much more acutely aware of not only encrypting all HTTP traffic, but also how that traffic is encrypted. Thanks to great tools like SSL Labs and more transparent alerting within browsers, end users and business partners have joined security practitioners in this awareness. As a result, effort is being spent to improve the configuration of SSL (or more precisely, TLS) termination points in the infrastructure. One of the biggest trends is the move to Elliptic Curve Cryptography or ECC ciphers.

Without further ado, here are the top 10 things to know when enabling ECC in your infrastructure:

Elliptic Curve Cryptography is used for many forms of encryption. The specifications for use of ECC in TLS can be found in IETF RFC 4492.

1. ECC key exchanges are not inherently “more secure” than RSA. ECC ciphers provide equivalent or better encryption strength with smaller key-lengths. For example, the 256-bit ECC key provides equivalent strength to a 3072-bit RSA key.
2. The goal of using ECC for HTTPS is to provide high performance encryption, which will tax the server far less than a 2048-bit (or stronger) RSA key exchange.
3. ECC ciphers can be enabled with the most common RSA certificates and public keys or with the newer ECDSA certificates and public keys, but an ECDSA certificate is not a requirement.
4. ECC ciphers have many possible curves. The most widely-supported curves in HTTPS are two of the NIST curves, P-256 and P-384. Other curves exist such as Curve25519 and Brainpool.
5. The aforementioned NIST curves go by some other names: secp256r1 and secp384r1, respectively.
6. Perfect Forward Secrecy, or PFS, can be provided with either RSA or ECC via the DHE- or ECDHE-based Diffie-Hellman Ephemeral cipher suites. Support for PFS is critical for preventing MITM attacks and preventing future decryption of previously recorded traffic. PFS support is also key criteria in SSL Labs grading and required by HTTP/2.
7. Since ECC as implemented in TLS automatically enables PFS, be sure to identify any passive systems such as IDS/IPS or WAF on a span port that may rely on the use of RSA key exchanges to decrypt traffic.
8. Some older browsers (or anything running on Windows XP) do not support ECDHE cipher suites, so be cautious if considering restricting the available ciphers to only ECDHE suites.
9. To ensure the use of ECC ciphers whenever possible in the client or server, place ECDHE cipher suites highest in the order of preference for the TLS handshake.

One bonus tip: I highly recommend reading Ivan Ristic’s book Bulletproof SSL & TLS to learn more about the effective encryption of HTTP traffic.

Encryption standards for TLS are changing at a faster pace than at any time in history. The IETF will soon ratify TLS 1.3, which will only support PFS ciphers and ECDHE will likely be preferred. This pace is driven by security research on SSL and TLS revealing vulnerabilities such as BEAST, Heartbleed, and LogJam. New vulnerability revelations around SSL and TLS aren’t likely stop emerging, so staying current with the latest encryption standards like ECC is vital to a comprehensive security practice. The term Elliptic Curve Cryptography certainly sounds daunting, but armed with this information, using ECC ciphers to improve the encryption behind the “S” in HTTPS should be easy.