Résumé

  • La RFC 8446, publiée en août 2018, place la négociation réelle de TLS 1.3 dans supported_versions. Les champs hérités legacy_version conservent 0x0303, numéro de TLS 1.2 : leur lecture isolée donne une fausse version de la connexion.
  • Un serveur capable de TLS 1.3 qui choisit TLS 1.2 doit terminer ServerHello.random par 44 4F 57 4E 47 52 44 01. Pour TLS 1.1 ou moins, le dernier octet devient 00. Le client TLS 1.3 qui reçoit l’une de ces marques dans une réponse d’ancienne version doit interrompre la négociation.
  • La RFC 7507 de 2015 traitait un autre recul : le client qui réessaie avec une version inférieure peut joindre TLS_FALLBACK_SCSV, et un serveur plus capable rejette ce repli indu. L’IANA enregistre la valeur et l’alerte correspondante.

Le vieux numéro au portique

Un analyste qui ne lit que ServerHello.legacy_version peut ranger une connexion TLS 1.3 parmi celles en TLS 1.2. La RFC 8446 fixe ce vieux champ à 0x0303 et déplace la décision dans supported_versions. Le mot « legacy » indique sa fonction : préserver la forme d’un échange plus ancien, pas témoigner de l’état cryptographique finalement exécuté. Une sonde qui traite la plaque comme la vérité de la connexion produit un relevé de sécurité trompeur.

Les équipements placés entre client et serveur expliquent cette concession. Certains connaissaient trop bien l’ancienne silhouette du protocole et faisaient échouer une négociation nouvelle. L’annexe D.4 de la RFC décrit un mode de compatibilité : identifiant de session client non vide, messages ChangeCipherSpec factices et autres signes familiers peuvent aider la négociation TLS 1.3 à passer. Lorsque les deux extrémités ont retenu TLS 1.3 dans l’extension, elles utilisent TLS 1.3. Le costume s’adresse aux appareils du milieu.

Ces appareils ont gagné un pouvoir très concret : laisser tomber le trafic inconnu suffisait à imposer des retouches au nouveau protocole. Ils n’ont pourtant aucune autorité légitime pour décider de la version protégée à la place des extrémités. Le standard a négocié l’apparence visible sur le fil ; il a conservé la décision dans une extension que les parties lisent. La distinction entre enveloppe et état exécuté est le cœur de l’affaire.

Huit octets pour démasquer un retour en arrière

La compatibilité d’apparence ne résout pas la possibilité d’un déclassement provoqué sur le trajet. Un serveur capable de TLS 1.3 qui négocie TLS 1.2 doit écraser les huit derniers octets de ServerHello.random avec 44 4F 57 4E 47 52 44 01. S’il négocie TLS 1.1 ou plus ancien, il utilise les mêmes sept premiers octets et termine par 00. Les sept premiers écrivent DOWNGRD en ASCII ; le dernier classe la version inférieure choisie.

Le client TLS 1.3 qui reçoit un ServerHello annonçant TLS 1.2 ou moins doit chercher les deux motifs. Une correspondance entraîne un abandon avec illegal_parameter. Il a appris que le serveur possédait une capacité plus récente alors que l’échange visible aboutissait à l’ancienne version. Une connexion ancienne qui fonctionne n’explique pas, à elle seule, pourquoi des parties capables de mieux n’ont pas retenu mieux.

La RFC donne à cette alarme une portée délimitée. Elle la présente comme protection supplémentaire limitée par rapport à l’échange Finished. Lorsque les suites utilisent des clés éphémères, la signature de l’ancienne négociation couvre les valeurs aléatoires ; avec RSA statique, ce bouclier manque. Le texte précise aussi que de nombreuses implémentations TLS 1.2 déjà déployées ne suivront pas cette nouvelle règle. Un signal de huit octets n’agit que si le serveur capable le produit et si le client capable le vérifie.

Un autre signal accompagnait la seconde tentative

La RFC 7507, publiée en 2015, parlait d’un mouvement différent. Après un échec, un client pouvait essayer de nouveau avec une version inférieure pour contourner un problème de compatibilité. Un adversaire capable de susciter l’échec pouvait provoquer ce recul. Le client indique alors la tentative avec TLS_FALLBACK_SCSV. Si le serveur prend en charge une version supérieure, il répond inappropriate_fallback. Le registre TLS de l’IANA conserve la valeur et l’alerte.

La marque de 2015 vient d’un client qui réessaie. Celle de 2018 est produite par un serveur capable de la nouvelle version dans sa valeur aléatoire. Chacune révèle un savoir différent au cours de la négociation. Les confondre sous l’étiquette générale de « protection contre le déclassement » effacerait la question décisive : qui savait qu’une meilleure version était disponible, et quand ?

Le costume n’était pas un bulletin de vote

L’annexe D.4 raconte la pression des infrastructures existantes sur la forme d’une norme nouvelle. TLS 1.3 a emprunté les gestes de l’ancienne négociation pour passer les appareils rigides. Le signal dans ServerHello.random trace une autre limite : la concession de forme ne vaut pas accord silencieux pour une rétrogradation imposée. Les extrémités gardent le choix de la version et un indice vérifiable de la capacité du serveur lorsque le résultat baisse.

Les textes officiels et le registre établissent les règles. Pour savoir si une connexion donnée a utilisé ce mode et émis la marque, il faudrait une capture datée et les données d’implémentation des deux extrémités. Le fait historique tient déjà : en 2018, TLS 1.3 a transporté son vrai choix dans une extension, gardé une vieille plaque à l’entrée et placé une alarme à la fin du hasard d’un serveur capable qui reculait.