Tout ce qui mérite d'être su, rien qui ne le mérite pas.
Ce qui a été enlevé
TLS 1.3 abandonne l'échange de clés RSA, le DH statique, les chiffrements en mode CBC, MD5 et SHA-1 lors de la négociation, la compression (attaques de type CRIME) et la renégociation. Seuls subsistent : ECDHE pour la confidentialité persistante, AES-GCM/ChaCha20-Poly1305 pour l'AEAD et SHA-256/384 pour le hachage des transcriptions. La liste des suites de chiffrement passe de plusieurs dizaines à cinq. C'est un avantage.
Qu'est-ce qui a changé dans la poignée de main ?
TLS 1.3 effectue un seul aller-retour pour l'établissement de la liaison (contre deux auparavant) et prend en charge la reprise sans interruption (0 RTT) pour les connexions répétées. Sur un émetteur-récepteur SMPP qui se reconnecte toutes les quelques heures, le gain de temps d'attente (RTT) est considérable. Plus important encore, la simplification de l'établissement de la liaison a éliminé la vulnérabilité aux attaques par rétrogradation qui affectait TLS 1.2 (POODLE, FREAK, Logjam).
Ce que les clients SMPP doivent vérifier
Trois points importants : votre bibliothèque cliente prend en charge TLS 1.3 (la plupart le font depuis 2022 ; vérifiez OpenSSL >= 1.1.1, JSSE sur JDK 11+, Go 1.12+). Le SMSC accepte TLS 1.3. La liste des algorithmes de chiffrement de votre côté inclut au moins TLS_AES_128_GCM_SHA256 ou TLS_CHACHA20_POLY1305_SHA256.
Là où TLS 1.2 persiste
Certaines anciennes piles SMSC (Acision sous RHEL 5, certains nœuds Huawei) sont limitées à TLS 1.2 car OpenSSL sous-jacent n'est plus pris en charge. Nous négocions une version inférieure lorsque cela est nécessaire, mais pour toute nouvelle liaison, TLS 1.3 est requis. À des fins d'audit PDPL, toutes les liaisons SMPP de production chez BroadNet utilisent TLS 1.3 avec l'épinglage de chiffrement.