TLS and Ciphers Suites
The content on this page is based on the RFCs for TLS 1.2 and TLS 1.3, RFC 5246 and RFC 8446 respectively. In addition, Cloudflare has a great guides to TLS. OWASP also offer recommendations for cipher suites.
Warning: TLS 1.1 and below has been deprecated since 2020.
Transport Layer Security (TLS), the successor to Secure Sockets Layer (SSL), is a protocol for secure network communication and is most frequently known trough its use in HTTPS. The goal of TLS is to achieve both integrity and confidentiality of the transmitted information between a client and a server.
TLS is initiated with a handshake, which after complete, the connection is considered secure for information exchange. Due to this TLS establishes a stateful connection.
The handshake utilizes both asymmetric and symmetric cryptography. The asymmetric keys are the public-private key-pair of the X.509v3 certificate which the server presents to the client.
By using this certificate, the client can authenticate the server. By verifying whether the certificate has been signed by a trusted Certificate Authority (CA), the trust of the CA is extended to the server. If the client also has a certificate, the server may verify the identity of the client as well in a similar manner.
Note: TLS uses negotiation between the client and the server to decide on both the TLS version and the cipher suites to use. Due to this, the list of cipher suites which the server offers are a trade-off between availability against confidentiality and integrity.
Cipher suites are made up of several components:
Key Exchange Algorithm: How the symmetric keys will be exchanged
Authentication Algorithm: How the authentication of the server and optionally the client will be performed
Data Encryption Algorithm: How the symmetric key will be used to encrypt the data
Message Authentication Algorithm: How the connection will perform integrity checks
Key Exchange | Authentication | Data Encryption | Message Authentication |
RSA | RSA | AES | MD5 |
DH | ECDSA | ChaCha20 | SHA256 |
ECDH | PSK | DES | POLY1305 |
// KeyExchange-Auth-Encrypton-MessageAuthECDHE-ECDSA-AES128-GCM-SHA256ECDHE-RSA-AES128-GCM-SHA256ECDHE-ECDSA-AES256-GCM-SHA384ECDHE-RSA-AES256-GCM-SHA384ECDHE-ECDSA-CHACHA20-POLY1305ECDHE-RSA-CHACHA20-POLY1305DHE-RSA-AES128-GCM-SHA256DHE-RSA-AES256-GCM-SHA384
Symmetric Block Ciphers: DES, AES
Symmetric Stream Ciphers: ChaCha20, RC4
Asymmetric Ciphers: RSA, DSA, DH, ECDH
AES encrypts blocks of 128-bits using a key of length 128, 192 or 256 bits while DES encrypts blocks of 64-bits. Stream ciphers on the other hand encrypt bit by bit.
$ cat /dev/urandom \ rngtest -c 100000rngtest 5Copyright (c) 2004 by Henrique de Moraes HolschuhThis is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.rngtest: starting FIPS tests...rngtest: bits received from input: 2000000032rngtest: FIPS 140-2 successes: 99927rngtest: FIPS 140-2 failures: 73rngtest: FIPS 140-2(2001-10-10) Monobit: 13rngtest: FIPS 140-2(2001-10-10) Poker: 9rngtest: FIPS 140-2(2001-10-10) Runs: 26rngtest: FIPS 140-2(2001-10-10) Long run: 25rngtest: FIPS 140-2(2001-10-10) Continuous run: 0rngtest: input channel speed: (min=5.989; avg=707.717; max=19073.486)Mibits/srngtest: FIPS tests speed: (min=18.393; avg=180.330; max=200.774)Mibits/srngtest: Program run time: 13286865 microseconds
"Concretely, this work illustrates the inability of the FIPS 140 family of tests to detect bias in three obviously flawed PRNGs." - On the unbearable lightness of FIPS 140-2 randomness tests, DOI:10.1109/TIFS.2020.2988505
"A mode of operation describes how to repeatedly apply a cipher's single-block operation to securely transform amounts of data larger than a block" - WIkipedia
"Block cipher modes of operation have been developed to eliminate the chance of encrypting identical blocks of text the same way" - WolfSSL
Mode of operations are general
Examples of modes:
ECB
CBC
CFB
OFB
CTR
In contrast to confidentiality-only modes, Authenticated Encryption (AE) schemes ensure both confidentiality and data authenticity.
By utilizing AE, the algorithm can recognize improperly-constructed ciphertexts and refuse to decrypt them. This prevents an attacker from requesting the decryption of any ciphertext unless it was generated using the encryption algorithm with knowledge of the plaintext and the key.
AE with associated data (AEAD) is a variant of AE that allows a recipient to check the integrity of both encrypted and unencrypted information in a message.
Example: AEAD is required by network packets where the header needs visibility, the payload needs confidentiality and both need integrity and authenticity.
Examples of modes:
GCM - widely used in TLS.
CCM
Reusing IVs https://en.wikipedia.org/wiki/Initialization_vector
"Reusing an IV with the same key in CTR, GCM or OFB mode results in XORing the same keystream with two or more plaintexts, a clear misuse of a stream, with a catastrophic loss of security."
Ciphertext indistinguishability https://en.wikipedia.org/wiki/Ciphertext_indistinguishability
