Résumé

  • Le « downgrade dance » relançait une négociation ratée avec une version plus ancienne. Une coupure fabriquée par un attaquant en position d’interception pouvait donc peser sur le choix du protocole.
  • Une fois SSL 3.0 et CBC obtenus, l’attaque Web décrite par les chercheurs exigeait encore des requêtes répétées contenant un secret et la modification des enregistrements ; l’effort moyen annoncé était de 256 requêtes par octet révélé.
  • TLS_FALLBACK_SCSV n’était pas un algorithme de chiffrement. Il signalait une tentative de repli afin que le serveur refuse localement une version inférieure à sa capacité réelle.

TLS savait déjà négocier ses versions. Le client annonçait son maximum, le serveur choisissait la meilleure version commune, et le résultat entrait dans la négociation authentifiée. Le mécanisme de compatibilité parallèle répondait à une autre réalité : des serveurs ou intermédiaires anciens cassaient parfois devant un ClientHello trop moderne. Des clients ont donc appris à recommencer plus bas.

Cette prudence commerciale modifiait la nature de l’échec. Une absence de réponse devenait une déclaration supposée sur les capacités du serveur. Or cette déclaration ne venait pas du serveur. Un adversaire placé sur le chemin pouvait supprimer les tentatives TLS 1.2, puis TLS 1.1 et TLS 1.0, jusqu’à ce que le client propose SSL 3.0 comme plafond.

POODLE exploitait ensuite une faiblesse propre à la protection CBC de SSL 3.0. Les octets arbitraires du bourrage n’étaient pas tous couverts de manière déterministe par le MAC. Dans le scénario Web du rapport original, l’attaquant faisait produire au navigateur des requêtes HTTPS portant un cookie, alignait l’octet recherché sur une limite de bloc, remplaçait un bloc chiffré et observait l’acceptation ou le rejet par le serveur. Une acceptation survenait en moyenne une fois sur 256 pour la condition testée, d’où 256 requêtes attendues par octet.

Ce chiffre ne décrit ni une durée garantie ni tous les systèmes TLS. Il suppose un intermédiaire actif, des requêtes influençables, une session SSL 3.0 en CBC et de nombreux essais. La simple présence de SSL 3.0 n’extrait pas un cookie, et tous les clients ne descendaient pas jusqu’à cette version.

La réponse devait donc séparer deux décisions. Supprimer SSL 3.0 réglait le protocole vulnérable. En attendant cette suppression, empêcher un faux besoin de compatibilité réglait le chemin d’accès à ce protocole.

RFC 7507 a donné à la seconde décision une forme minimale. La valeur {0x56,0x00} apparaît parmi les suites proposées, mais ne peut jamais être choisie comme suite cryptographique. Elle signifie que le ClientHello de version inférieure est une reprise. Si le serveur active une version plus haute, il renvoie l’alerte fatale inappropriate_fallback(86).

Le serveur n’attribue pas l’incident. Il compare deux faits locaux : la version annoncée par le client et son propre maximum activé. C’est précisément la force du mécanisme, mais aussi sa limite. Une panne réseau ordinaire peut produire le même repli ; l’alerte ne prouve donc pas une attaque. Et le RFC précise que SCSV ne remplace pas une négociation correcte.

La transition a eu une fin. OpenSSL a ajouté la protection dans les versions 1.0.1j, 1.0.0o et 0.9.8zc. RFC 7568 a ensuite interdit SSL 3.0. RFC 8996 a plus tard retiré TLS 1.0 et 1.1 et rendu RFC 7507 obsolète, TLS 1.3 utilisant un signal différent dans ServerHello.Random.

Une protection transitoire peut donc être bien conçue sans devenir éternelle. Elle doit rendre une exception observable, limiter son effet et préparer sa propre disparition.