Résumé

  • Après que le pair récepteur a annoncé les algorithmes acceptés, le RFC 8879 autorise un endpoint TLS 1.3 à remplacer son message Certificate par CompressedCertificate. L’annonce permet une représentation ; elle ne prouve ni l’usage de la compression ni l’octroi d’un budget de ressources illimité.
  • uncompressed_length doit correspondre exactement au message reconstruit, la sortie ne doit jamais le dépasser et une limite locale peut rester bien inférieure au plafond sur 24 bits de TLS. Ces décisions précèdent l’authentification que le certificat rendra peut-être possible.
  • Décompresser n’est pas valider. Une preuve exploitable sépare offre, algorithme choisi, octets comprimés, longueur déclarée et réelle, empreinte du message reconstruit, chaîne analysée, résultat de validation, alerte, repli et issue de la connexion.

Une allocation avant toute identité

Prenons un terminateur TLS qui ouvre plusieurs milliers de connexions simultanées. Le client a placé zlib, Brotli et Zstandard dans compress_certificate. Le serveur renvoie quelques kilo-octets avec l’algorithme Brotli et affirme que le message Certificate reconstitué fera douze mégaoctets.

Le certificat censé identifier le serveur est encore enfermé dans ce contenu. Le récepteur ne peut donc pas invoquer sa CA, ses noms ou sa signature pour décider de l’allocation. Il vérifie d’abord que Brotli faisait partie de son offre, compare la taille déclarée à sa limite locale, borne la sortie du décompresseur et refuse toute différence entre longueur promise et longueur obtenue.

Cette chronologie révèle la véritable surface de contrôle. Le serveur choisit une représentation parmi les options offertes ; le client reste maître des transformations qu’il exécute et du coût acceptable avant authentification. Une capacité annoncée n’est pas un droit de réservation sur la mémoire du pair.

Le cadrage TLS autorise au maximum 16 777 215 octets pour ce message, mais le RFC 8879 permet une limite d’implémentation plus basse. Cette même limite doit régir la voie comprimée et la voie ordinaire. Accepter un objet décompressé que l’on aurait refusé en clair transformerait l’optimisation en contournement de politique.

L’annonce, le choix et l’exécution sont trois faits

L’extension est unidirectionnelle. Dans ClientHello, le client annonce les algorithmes avec lesquels il peut décompresser le certificat du serveur. Dans CertificateRequest, le serveur indique ceux qu’il accepte pour le certificat du client. Aucun message de réponse ne confirme l’extension.

L’émetteur peut sélectionner un algorithme annoncé ou envoyer le message Certificate habituel. Voir compress_certificate dans une capture prouve donc une aptitude de réception, pas la présence ultérieure de CompressedCertificate. Compter les offres comme des handshakes comprimés revient à mesurer une possibilité comme une exécution.

La direction ne se déduit pas non plus. Un client capable de recevoir un certificat serveur comprimé n’a rien déclaré sur la compression de son propre certificat. Celle-ci dépend d’une annonce distincte dans CertificateRequest. Une bibliothèque peut par ailleurs activer la réception tout en coupant l’émission, ou l’inverse.

Le mécanisme ne vaut que pour TLS 1.3 et les versions suivantes. Avec TLS 1.2, l’extension est ignorée. Il ne faut pas la confondre avec la compression générale des records TLS, historiquement associée à CRIME. Ici, un message de handshake est transformé, puis le traitement normal des certificats reprend.

Ce qui est comprimé doit être nommé correctement

L’entrée de l’algorithme est le message Certificate encodé qui aurait circulé sans compression : contexte de requête, liste des certificats et extensions de chaque entrée. Le protocole ne propose pas de comprimer séparément quelques X.509 puis de reconstruire une chaîne « équivalente » au gré de l’application.

Cette précision impose deux identités de preuve. L’empreinte des octets comprimés décrit la représentation reçue et l’algorithme choisi. L’empreinte du message Certificate reconstitué décrit l’objet exact livré au parseur TLS. Les empreintes du certificat terminal et des intermédiaires identifient ensuite les objets dont la validation a examiné l’autorité.

Deux algorithmes peuvent produire des octets différents pour la même entrée. Une nouvelle version de bibliothèque peut également modifier le résultat comprimé sans changer le message reconstruit. Une seule empreinte du contenu comprimé ne permet donc pas d’affirmer quelle chaîne logique a été présentée.

La même règle gouverne la précompression. OpenSSL permet de préparer et stocker les représentations comprimées des certificats serveur. Les certificats client sont comprimés à la demande parce que leur contexte provient du CertificateRequest propre au handshake. Côté serveur, un cache reste valable uniquement s’il correspond au message Certificate exact. Renouvellement de chaîne, changement d’intermédiaire ou d’extension par entrée doit rompre ce lien.

La longueur exacte est une barrière de sûreté

CompressedCertificate transporte l’algorithme, une longueur de sortie sur 24 bits et le contenu comprimé. Si la décompression échoue ou si le nombre d’octets obtenus diffère de la déclaration, le récepteur termine la connexion avec bad_certificate. Il doit empêcher le décompresseur de dépasser la borne annoncée.

Cette longueur facilite le rejet précoce ; elle n’atteste ni l’honnêteté de l’émetteur ni l’innocuité du résultat. Une valeur conforme au plafond du protocole peut rester incompatible avec le budget d’un service très concurrent. La politique locale doit intervenir avant qu’une taille plausible, répétée sur des milliers de connexions, devienne une saturation collective.

Le contenu comprimé n’est même pas obligé d’être plus court. Les tests de BoringSSL comprennent volontairement des transformations qui réduisent, agrandissent ou rendent les données aléatoires. La validité porte sur une reconstruction exacte et bornée. Un bon ratio est un résultat d’optimisation, pas une condition du protocole.

Il faut donc dissocier ratio, sûreté et service rendu. Mesurer longueur annoncée, sortie réelle, pic d’allocation, durée de décompression et classe d’échec. Un ratio spectaculaire peut cacher une forte pression mémoire ; un gain modeste peut éviter un paquet ou un aller-retour décisif. Aucun de ces effets n’est contenu dans le pourcentage seul.

Après décompression, la confiance recommence à zéro

Le message reconstitué est traité comme s’il avait été envoyé sans compression. Le pair analyse la liste, construit et valide la chaîne, vérifie noms et dates, applique sa politique locale, puis contrôle CertificateVerify dans la transcription TLS 1.3. La compression ne répare ni une chaîne expirée, ni un mauvais nom, ni une signature incorrecte.

La télémétrie doit préserver cette taxonomie. Algorithme non offert : échec de négociation. Sortie excessive, erreur du codec ou longueur différente : échec de reconstruction. Structure reconstituée invalide : échec de parsing. CA inconnue ou nom faux : échec de validation. CertificateVerify incorrect : échec d’authentification du handshake.

Réunir tous ces cas sous « erreur de certificat TLS » efface l’endroit où la décision a été prise. Inversement, decompression_success ne prouve ni l’identité attendue, ni la possession de la clé privée, ni l’autorisation de l’action applicative suivante.

Le code exécuté rend ces limites concrètes. BoringSSL construit d’abord le message Certificate ordinaire, enregistre sa taille exacte, appelle le compresseur sélectionné et sérialise le résultat. OpenSSL expose des contrôles distincts d’émission et de réception, des préférences et la précompression serveur. Le registre, la branche de code et la configuration de l’application restent trois faits indépendants.

Mesurer le changement utile, pas seulement les octets retirés

Les chaînes occupent souvent la majorité du premier handshake. Les comprimer peut réduire les paquets et parfois éviter un aller-retour. Le bénéfice dépend néanmoins de la chaîne, de la congestion, des pertes, du packing des records, du CPU, du cache et de l’algorithme réellement commun.

La mesure part de la longueur du message Certificate encodé, non de fichiers PEM sur disque. Elle relie offre et direction, algorithme utilisé, tailles, records, paquets, retransmissions, CPU, mémoire, validation et durée totale. Un groupe de contrôle envoie la même identité de certificat par la voie non comprimée.

Le repli ordinaire n’est pas un échec de sécurité. Sans algorithme commun, le serveur peut envoyer Certificate. Une hausse soudaine du repli peut toutefois signaler un client différent, une option de build perdue ou une terminaison TLS déplacée. La voie de repli doit conserver exactement les mêmes limites et règles de confiance.

Sources