Résumé

  • Dans une négociation TLS complète, False Start laissait le client envoyer des données sous les nouvelles clés après son Finished, pendant que le Finished du serveur revenait encore.
  • La négociation ordinaire restait obligatoire ; avancer la libération des données exigeait l'accord de l'application, des listes cryptographiques étroites, un protocole connu et un traitement explicite de l'échec.

Une donnée chiffrée a dépassé la dernière preuve

Dans l'ordre normal de TLS 1.2, le client traite le certificat et l'échange de clés du serveur, envoie ChangeCipherSpec puis Finished et attend les messages correspondants du serveur. La négociation n'est achevée qu'après vérification du Finished opposé.

False Start déplaçait la première donnée applicative dans cette attente. Le client avait déjà calculé les nouvelles clés et envoyé sa propre preuve. Son premier enregistrement chiffré partait vers le serveur tandis que la preuve finale de celui-ci revenait en sens inverse.

RFC 7918 qualifie le succès de validation rétroactive. Si le Finished du serveur arrive et se vérifie, la négociation ordinaire est valide ; seule la chronologie du trafic change. Le tour réseau n'a pas disparu : le client a utilisé son temps avant d'en recevoir le résultat.

Le client savait beaucoup, mais pas encore tout

Au moment du départ, le client a vu ServerHello, la suite cryptographique, le certificat et les paramètres d'échange nécessaires. L'enregistrement utilise le nouveau Cipher Spec. False Start n'est donc ni du texte clair ni un message aveugle envoyé avec ClientHello.

Il manque pourtant une propriété décisive. Le Finished du serveur confirme que le pair possède les mêmes secrets et a vu la même transcription. S'il n'arrive pas ou ne correspond pas, la négociation n'est jamais validée. Selon l'ordre normal, aucune donnée applicative ne serait partie ; avec False Start, elle a déjà franchi le transport.

La question n'est pas seulement « le canal chiffre-t-il ? », mais « quelles données peut-on libérer avant la confirmation finale du transcript ? »

Un choix du client, pas une extension d'autorisation

RFC 7918 n'introduit pas un message par lequel le serveur accorde False Start. Il modifie facultativement le comportement du client. Un serveur compatible tolère simplement des enregistrements protégés plus tôt que son automate ne les attend habituellement.

Cette compatibilité pouvait provenir d'un profil applicatif ou d'une connaissance externe. Une absence de refus ne valait pas consentement. Les middleboxes et serveurs qui réinitialisaient la connexion révélaient une hypothèse d'ordre, non une faiblesse du chiffrement.

L'application devait demander l'option. Elle seule connaissait la valeur de l'attente économisée et la sensibilité du premier message. Une bibliothèque TLS générique ne pouvait pas décider qu'une lecture sans effet et une commande irréversible supportaient la même libération anticipée.

Les listes blanches enfermaient le raccourci

RFC 7918 impose des listes autorisées pour la version, le chiffrement symétrique, l'échange de clés, ses paramètres et, le cas échéant, le type de certificat client. Les familles DHE et ECDHE recommandées apportaient la confidentialité persistante. Le doute excluait False Start.

Ces listes protégeaient contre une dégradation qui aurait fait partir les données sous une combinaison trop faible. Elles transformaient toutefois une optimisation en politique de cycle de vie. Une nouvelle valeur par défaut, un fallback ou une mise à jour de bibliothèque pouvait élargir l'éligibilité sans décision de l'application.

L'état de production important n'était donc pas « TLS a réussi », mais « cette combinaison précise avait-elle été approuvée pour parler avant la dernière preuve ? »

Le langage applicatif devait déjà être choisi

RFC 7301 place ALPN dans l'échange hello : le client propose des protocoles dans ClientHello et le serveur choisit dans ServerHello. Le client connaît ainsi le langage applicatif avant la décision False Start.

ALPN ne donne aucune permission de libération anticipée. Il évite qu'un client envoie rapidement des octets sans savoir quelle grammaire le serveur appliquera. L'accord de l'application, la sélection ALPN et les contraintes cryptographiques doivent désigner le même profil.

Le chiffrement ne corrige pas un message interprété par le mauvais protocole. L'optimisation devait donc fermer la sélection avant d'avancer la donnée.

L'échec arrêtait la suite sans rappeler les octets

Si le Finished serveur se vérifie, la négociation est validée et l'application continue. S'il est absent ou incorrect, le client doit échouer : des messages de négociation ont pu être supprimés, modifiés ou injectés. Il ne doit pas abaisser l'erreur d'authentification en simple timeout ni répéter automatiquement une action dangereuse.

Fermer la connexion ne retire toutefois pas ce qui a déjà atteint le pair. Voilà la frontière irréversible de False Start. Le chiffrement protège le trajet ; il ne fournit pas rétroactivement la preuve qui manquait au moment de la décision de divulgation.

False Start n'était pas le 0-RTT

TLS 1.3 a conçu des flux plus courts et placé False Start hors de son champ. Son 0-RTT est une autre construction : lors d'une reprise, la donnée peut suivre immédiatement ClientHello sous des clés issues d'un PSK antérieur. Elle n'est pas confidentielle vers l'avant et ne garantit pas l'absence de rejeu entre connexions.

False Start opère pendant une négociation complète, sous des clés fraîches, après le Finished du client. Son risque central est la preuve Finished du serveur encore pendante, non le rejeu interconnexion d'une donnée PSK.

RFC 8470 a créé pour HTTP l'en-tête Early-Data et la réponse 425 Too Early afin de gérer le rejeu du 0-RTT. Ils ne réparent pas False Start et ne doivent pas servir à étiqueter rétroactivement ses requêtes.

RFC 9325 exige une spécification applicative avant le 0-RTT et traite ALPN et la cohérence des fermes de serveurs comme des contrôles. La parenté est une discipline de portée ; les propriétés cryptographiques restent différentes.

Sources et limites

Les sources sont RFC 5246, RFC 7301, RFC 7918, RFC 8446, RFC 8470 et RFC 9325. Elles n'établissent pas le déploiement actuel. False Start n'envoyait pas de texte clair, ne sautait pas le certificat, ne reprenait pas une ancienne session et n'ajoutait pas une extension serveur dédiée.