Aller au contenu principal

Annexe E. Rétrocompatibilité (Backward Compatibility)

Cette annexe traite des problèmes de compatibilité entre TLS 1.2 et les versions antérieures.

E.1. Compatibilité avec TLS 1.0/1.1 et SSL 3.0 (Compatibility with TLS 1.0/1.1 and SSL 3.0)​

En raison de nouvelles fonctionnalités et de certains changements structurels, il n'y a pas d'interopérabilité directe entre TLS 1.2 et TLS 1.1, TLS 1.0 et SSL 3.0. Cependant, TLS 1.2 contient un mécanisme par lequel une implémentation TLS 1.2 peut négocier avec les versions antérieures.

E.1.1. Négociation de version​

TLS fournit un mécanisme intégré pour la négociation de version dans le cadre de la poignée de main:

  1. Version dans ClientHello:

    • Le client indique la version la plus élevée qu'il prend en charge dans le ClientHello
    • Les implémentations DEVRAIENT indiquer TLS 1.2 (version 3) dans le ClientHello

  2. Version dans ServerHello:

    • Le serveur sélectionne la version la plus élevée prise en charge par lui-même et le client
    • Si le serveur ne prend pas en charge la version suggérée par le client, il sélectionne une version inférieure

  3. Version de la couche d'enregistrement:

    • La version de l'enregistrement ClientHello DEVRAIT être définie sur 1 (TLS 1.0) pour une compatibilité maximale
    • Les enregistrements suivants utilisent la version négociée

E.1.2. Extensions​

TLS 1.2 introduit de nouvelles extensions et des modifications aux extensions existantes:

  • Extension signature_algorithms: Les clients TLS 1.2 DOIVENT inclure cette extension
  • Les serveurs de versions plus anciennes ignoreront les extensions qu'ils ne comprennent pas

E.1.3. Suites de chiffrement​

Certaines suites de chiffrement sont spécifiques à TLS 1.2:

  • Suites de chiffrement utilisant le PRF SHA-256
  • Nouvelles suites de chiffrement AEAD

Lors de la négociation avec des versions antérieures, ces suites de chiffrement NE DEVRAIENT PAS être offertes dans le ClientHello.

E.1.4. Recommandations d'implémentation​

Les implémentations client DEVRAIENT:

  • Prendre en charge plusieurs versions TLS
  • Annoncer la version la plus élevée prise en charge dans ClientHello
  • Être prêtes à accepter une version inférieure
  • Implémenter la protection contre le repli de version (SCSV)

Les implémentations serveur DEVRAIENT:

  • Prendre en charge plusieurs versions TLS pour une large compatibilité
  • Préférer la version de protocole la plus élevée
  • Gérer correctement les ClientHellos des versions antérieures

Exemple de flux de négociation:

Client (prend en charge TLS 1.2, 1.1, 1.0)
  -> ClientHello (version=3.3)
     Versions prises en charge: TLS 1.2, 1.1, 1.0

Serveur (prend en charge uniquement TLS 1.1, 1.0)
  <- ServerHello (version=3.2)
     Sélectionné: TLS 1.1

La connexion se poursuit en utilisant TLS 1.1

E.2. Compatibilité avec SSL 2.0 (Compatibility with SSL 2.0)​

SSL 2.0 NE DEVRAIT PAS être utilisé dans les nouvelles implémentations. Cependant, pour la compatibilité avec les systèmes hérités, certaines implémentations peuvent avoir besoin de comprendre les ClientHellos au format SSL 2.0.

E.2.1. ClientHello SSL 2.0​

Le ClientHello SSL 2.0 a un format différent:

uint16 msg_length;          /* Le bit le plus élevé DOIT être 1 */
uint8 msg_type;             /* DOIT être 1 */
Version version;            /* Version souhaitée par le client */
uint16 cipher_spec_length;  /* Ne peut pas être 0 */
uint16 session_id_length;   /* DOIT être 0 ou 16 */
uint16 challenge_length;    /* Ne peut pas être 0 */
CipherSpec cipher_specs[...];
SessionID session_id;
Challenge challenge;

E.2.2. Gestion du ClientHello SSL 2.0​

Un serveur TLS 1.2 PEUT accepter un ClientHello encapsulé au format SSL 2.0, mais DOIT:

  1. Vérifier le bit le plus élevé de msg_length
  2. Vérifier la validité du format
  3. Le convertir au format TLS pour le traitement
  4. Répondre avec un ServerHello au format TLS

E.2.3. Considérations de sécurité​

Important: La prise en charge des ClientHellos au format SSL 2.0 ne signifie pas la prise en charge du protocole SSL 2.0 lui-même. SSL 2.0 a de nombreuses vulnérabilités de sécurité connues et NE DOIT PAS être négocié pour utilisation.

E.2.4. Recommandations d'implémentation​

  • Les clients TLS 1.2 NE DOIVENT PAS envoyer de ClientHellos au format SSL 2.0
  • La prise en charge par le serveur des ClientHellos au format SSL 2.0 est maintenant PEUT, plutôt que DEVRAIT
  • L'envoi de ClientHellos au format SSL 2.0 est NE DEVRAIT PAS
  • Les futures versions TLS peuvent changer cela en NE DEVRAIT PAS prendre en charge

E.3. Éviter le retour en arrière de version par homme du milieu (Avoiding Man-in-the-Middle Version Rollback)​

Les versions antérieures du protocole étaient vulnérables aux attaques de retour en arrière de version où un attaquant pouvait forcer une connexion à utiliser une version de protocole antérieure (plus faible).

E.3.1. Mécanismes de protection​

TLS 1.2 utilise plusieurs mécanismes pour empêcher le retour en arrière de version:

  1. Vérification du message Finished:

    • Le message Finished contient un hachage de tous les messages de poignée de main
    • Inclut les champs de version de ClientHello et ServerHello
    • Toute modification de version fera échouer la vérification de Finished

  2. TLS_FALLBACK_SCSV:

    • Valeur de suite de chiffrement de signalisation définie dans RFC 7507
    • Les clients incluent cette valeur lors de la nouvelle tentative d'une connexion avec une version inférieure
    • Le serveur rejette la connexion s'il prend en charge une version supérieure

E.3.2. Exigences d'implémentation​

Les clients DOIVENT:

  • Enregistrer les versions précédemment tentées
  • Inclure TLS_FALLBACK_SCSV lors de la nouvelle tentative de rétrogradation
  • Vérifier le message Finished

Les serveurs DOIVENT:

  • Vérifier la présence de TLS_FALLBACK_SCSV
  • Envoyer une alerte inappropriate_fallback si une version supérieure est prise en charge
  • Calculer et vérifier correctement le message Finished

E.3.3. Exemples de scénarios​

Connexion normale:

Client -> ClientHello (TLS 1.2)
Serveur <- ServerHello (TLS 1.2)
... Poignée de main normale ...
Succès!

Rétrogradation légitime:

Client -> ClientHello (TLS 1.2)
Serveur <- ServerHello (TLS 1.1)
... Poignée de main TLS 1.1 ...
Succès!

Attaque détectée:

Client -> ClientHello (TLS 1.2)
L'attaquant modifie en (TLS 1.0)
Serveur <- ServerHello (TLS 1.0)
... La poignée de main continue ...
Client -> Finished (échec de la vérification!)
Connexion abandonnée!

Nouvelle tentative avec SCSV:

Client -> ClientHello (TLS 1.2) - Échec
Client -> ClientHello (TLS 1.1, TLS_FALLBACK_SCSV)
Le serveur détecte SCSV et prend en charge TLS 1.2
Serveur <- Alert: inappropriate_fallback
Connexion abandonnée - Attaque de rétrogradation détectée!

Note: Pour des informations complètes sur la compatibilité et des explications détaillées, veuillez vous référer au texte complet de l'annexe E de la RFC 5246.

Dernière mise à jour le