Every SSL connection begins with a handshake, during which the two parties communicate their capabilities to the other side, perform authentication, and agree on their session keys. The session keys are then used to encrypt the rest of the conversation (session), possibly spanning multiple connections. They are deleted afterwards. The goal of the key exchange phase is to enable the two parties to negotiate the keys securely; in other words, to prevent anyone else from learning these keys.
Several key exchange mechanisms exist, but, at the moment, by far the most commonly used one is based on RSA, where the server’s private key is used to protect the session keys. This is an efficient key exchange approach, but it has an important side-effect: anyone with access to a copy of the server’s private key can uncover the session keys and decrypt the conversation.
An alternative to the RSA-based key exchange is to use the ephemeral Diffie-Hellman algorithm, which is slower, but generates session keys in such a way that only the two parties involved in the communication can obtain them. No one else can, even if they have access to the server’s private key.1
SSL supports forward secrecy using two algorithms, the standard Diffie-Hellman (DHE) and the adapted version for use with Elliptic Curve cryptography (ECDHE).
DHE is significantly slower
ECDHE too is slower, but not as much as DHE.
BIG-IP LTM F5 11.6.0
ECDHE+AES-GCM:NATIVE:!MD5:!EXPORT:!DES:!DHE:!EDH:!RC4:!ADH:!SSLv3:!TLSv1
This disables
- SSLv3 is obsolete and insecure.
- EXPORT causes weak DH key exchange parameter
-
SHA-1 cryptographic hash algorithm is considered too weak to be safely used as part of the public web PKI.
