Couche d’enregistrement TLS et suites de chiffrement

La couche des enregistrements TLS est la sous-couche de transport de TLS. Elle fragmente les données en enregistrements de 16 Ko maximum, les compresse éventuellement (TLS 1.2 uniquement), les chiffre avec AEAD et ajoute un en-tête de 5 octets.

Octet 0 : ContentType (20=ChangeCipherSpec, 21=Alerte, 22=Établissement de la connexion, 23=ApplicationData). Octets 1-2 : version héritée (0x0303 pour la compatibilité avec TLS 1.2). Octets 3-4 : longueur de la charge utile suivante.

Dans TLS 1.3, chaque enregistrement est chiffré avec AEAD (par exemple, AES-GCM). Le nonce est dérivé en combinant par XOR le numéro de séquence implicite et l’IV de trafic. L’AAD est l’en-tête d’enregistrement de 5 octets. L’étiquette d’authentification est ajoutée à la fin.

TLS_AES_128_GCM_SHA256 = échange de clés (ECDHE implicite dans TLS 1.3) + AES-128-GCM (AEAD) + SHA-256 (pour HKDF). Dans TLS 1.2 : TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 nomme explicitement tous les composants.

TLS 1.3 interdit : RC4 (flux de clés biaisé), 3DES (attaque par rencontre au milieu, Sweet32), le mode CBC (BEAST, Lucky13, POODLE), le chiffrement NULL, les chiffrements de niveau export (40 bits), ainsi que MD5/SHA-1 dans la PRF. Seules les suites AEAD subsistent.

Les grands enregistrements TLS sont divisés en fragments de ≤16 KB. Chaque fragment est chiffré indépendamment. Le récepteur réassemble les enregistrements avant de les transmettre à la couche applicative. Les limites de fragmentation n’ont aucune signification sémantique.

Les alertes sont envoyées sous forme d’enregistrements TLS avec ContentType=21. Deux octets : niveau (1=warning, 2=fatal) + description (0=close_notify, 40=handshake_failure, 42=bad_certificate, 70=protocol_version). Les alertes fatales mettent fin à la connexion.

Le numéro de séquence propre à chaque enregistrement commence à 0 et est incrémenté de 1. Il est complété jusqu’à la longueur de l’IV (12 octets pour GCM), puis combiné par XOR avec l’IV du trafic. Cela empêche la réutilisation d’un nonce entre les enregistrements sans transmission explicite du nonce.

Privilégiez TLS_AES_256_GCM_SHA384 pour une sécurité de 256 bits. Utilisez TLS_CHACHA20_POLY1305_SHA256 sur les appareils mobiles ou embarqués dépourvus d’AES-NI. Évitez les suites de 128 bits pour les données très sensibles conservées à long terme.

DTLS (RFC 6347) adapte TLS à UDP. Il ajoute des numéros de séquence dans les en-têtes des enregistrements, gère le réordonnancement et utilise un échange initial fondé sur un cookie pour empêcher les attaques par déni de service (DoS). Il est utilisé dans WebRTC, les VPN et les protocoles IoT.

Utilisez le module ssl ou scapy pour capturer les enregistrements TLS. Lorsque SSLKEYLOGFILE est défini, Wireshark déchiffre automatiquement les enregistrements. La méthode ssl.SSLSocket.read() de Python déchiffre les données de manière transparente au niveau de la couche applicative.

Contre quoi le numéro de séquence protège-t-il dans le chiffrement des enregistrements de TLS 1.3 ?

Vous comprenez maintenant la structure des enregistrements TLS, le chiffrement AEAD, la dérivation des nonces et la sélection des suites cryptographiques. Ensuite : la manière dont TLS valide les certificats du serveur pendant la négociation.