TLS stands for Transport Layer Security. It is a protocol that provides privacy and data integrity between two communicating applications. It’s the most widely deployed security protocol used today replacing Secure Socket Layer (SSL), and is used for web browsers and other applications that require data to be securely exchanged over a network.
TLS ensures that a connection to a remote endpoint is the intended endpoint through encryption and endpoint identity verification. The versions of TLS, to date, are TLS 1.3, 1.2, 1.1, and 1.0.
I will not describe the SSL/TLS protocols meticulously so you have to look at this as an introduction. I will discuss only the most important things because we have some great documents which describe this protocol in a great deal of detail:
- Bulletproof SSL and TLS
- Cryptology ePrint Archive
- Every byte of a TLS connection explained and reproduced - TLS 1.2
| PROTOCOL | RFC | PUBLISHED | STATUS |
|---|---|---|---|
| SSL 1.0 | Unpublished | Unpublished | |
| SSL 2.0 | 1995 | Depracated in 2011 (RFC 6176) | |
| SSL 3.0 | 1996 | Depracated in 2015 (RFC 7568) | |
| TLS 1.0 | RFC 2246 | 1999 | Deprecation in 2020 |
| TLS 1.1 | RFC 4346 | 2006 | Deprecation in 2020 |
| TLS 1.2 | RFC 5246 | 2008 | Still secure |
| TLS 1.3 | RFC 8446 | 2018 | Still secure |
Useful resources:
The differences between TLS 1.2 and TLS 1.3 are presented in the following illustrations (every byte explained and reproduced):
The full TLS 1.2 handshake looks like this:
This infographic comes from ldapwiki - How SSL-TLS Works.
For TLS 1.3 is different:
By the way, the How SSL-TLS Works from ldapwiki is an amazing explanation.
🔖 Use only strong ciphers - Hardening - P1
🔖 Use more secure ECDH Curve - Hardening - P1
To secure the transfer of data, TLS/SSL uses one or more cipher suites. A cipher suite is a combination of authentication, encryption, and message authentication code (MAC) algorithms. They are used during the negotiation of security settings for a TLS/SSL connection as well as for the transfer of data.
There are essentially 4 different parts of a TLS 1.2 cipher suite:
- Key exchange - what asymmetric crypto is used to exchange keys?
Examples:RSA,DH,ECDH,DHE,ECDHE,PSK - Authentication/Digital Signature Algorithm - what crypto is used to verify the authenticity of the server?
Examples:RSA,ECDSA,DSA - Cipher/Bulk Encryption Algorithms - what symmetric crypto is used to encrypt the data?
Examples:AES,CHACHA20,Camellia,ARIA - MAC - what hash function is used to ensure message integrity?
Examples:SHA-256,POLY1305
For example, the TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256 uses ephemeral elliptic curve Diffie-Hellman (ECDHE) to exchange keys, providing forward secrecy. Because the parameters are ephemeral, they are discarded after use and the key that was exchanged cannot be recovered from the traffic stream without them. RSA_WITH_AES_128_CBC_SHA256 - this means that an RSA key exchange is used in conjunction with AES-128-CBC (the symmetric cipher) and SHA256 hashing is used for message authentication. P256 is an type of elliptic curve.
Look at the following explanation for TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:
| PROTOCOL | KEY EXCHANGE | AUTHENTICATION | CIPHER | HASHING |
|---|---|---|---|---|
TLS |
ECDHE |
ECDSA |
AES_128_GCM |
SHA256 |
TLS is the protocol. Starting with ECDHE we can see that during the handshake the keys will be exchanged via ephemeral Elliptic Curve Diffie Hellman (ECDHE). ECDSA is the authentication algorithm. AES_128_GCM is the bulk encryption algorithm: AES running Galois Counter Mode with 128-bit key size. Finally, SHA-256 is the hashing algorithm.
The client and the server negotiate which cipher suite to use at the beginning of the TLS connection (the client sends the list of cipher suites that it supports, and the server picks one and lets the client know which one). The choice of elliptic curve for ECDH is not part of the cipher suite encoding. The curve is negotiated separately (here too, the client proposes and the server decides).
Look also at this table with cipher suite definitions.
🔖 Use strong Key Exchange with Perfect Forward Secrecy - Hardening - P1
The goal in Diffie-Hellman key exchange (DHKE) is for two users to obtain a shared secret key, without any other users knowing that key. The exchange is performed over a public network, i.e. all messages sent between the two users can be intercepted and read by any other user.
The protocol makes use of modular arithmetic and especially exponentials. The security of the protocol relies on the fact that solving a discrete logarithm (the inverse of an exponential) is practically impossible when large enough values are used.
DHE (according to RFC 5246) and EDH are the same (EDH in OpenSSL-speak, DHE elsewhere). EDH isn't a standard way to state it, but it doesn't have another usual meaning. ECC can stand for "Elliptic Curve Certificates" or "Elliptic Curve Cryptography". Elliptic curve certificates are commonly called ECDSA. Elliptic curve key exchange is called ECDH. If you add another 'E' to the latter (ECDHE), you get ephemeral.
| TYPE | ELLIPTIC CURVE | EPHERMAL | KEY ROTATION | PFS | DHPARAM FILE |
|---|---|---|---|---|---|
DHE |
no | yes | yes | yes | yes |
ECDH |
yes | no | no | no | no |
ECDHE |
yes | yes | yes | yes | no |
Using DHE means even the g and p parameters may be randomly generated, but as this is a very expensive process (because you need to find a safe prime), computationally seen, you usually don't do this.
However, when you're doing a DH (without the "E") key exchange, the server has a certificate, which embeds a static, public Diffie-Hellman key, i.e. gxmodp as well as g and p allowing you to save an additional signature (e.g. using RSA or ECDSA) to verify the authenticity of the DH parameter. So while the server's DH value is static, the client still usually chooses a random value for security and storage-reduction reasons. Obviously fixing the parameters in the certificate implies they can't be changed at run-time.
Ephermal Diffie-Hellman (ECDHE/DHE) generates a new key for every exchange (on-the-fly), which enables Perfect Forward Secrecy (PFS). Next, it signs the public key with its RSA or DSA or ECDSA private key, and sends that to the client. The DH key is ephemeral, meaning that the server never stores it on its disk; it keeps it in RAM during the session, and discarded after use. Being never stored, it cannot be stolen afterwards, and that's what PFS comes from.
Forward Secrecy is the prime feature of the ephemeral version of Diffie-Hellman which means if the private key of the server gets leaked, his past communications are secure. Ephemeral Diffie-Hellman doesn't provide authentication on its own, because the key is different every time. So neither party can be sure that the key is from the intended party.
The ECDHE is a variant of the Diffie-Hellman protocol which uses elliptic curve cryptography to lower computational, storage and memory requirements. The perfect forward secrecy offered by DHE comes at a price: more computation. The ECDHE variants uses elliptic curve cryptography to reduce this computational cost.
Fixed Diffie-Hellman (ECDH and DH) on the other hand uses the same Diffie-Hellman key every time. Without any DH exchange, you can only use RSA in encryption mode.
These parameters aren't secret and can be reused; plus they take several seconds to generate. The openssl dhparam ... step generates the DH params (mostly just a single large prime number) ahead of time, which you then store for the server to use.