1. Introduction

L'objectif principal du protocole TLS est de fournir la confidentialité et l'intégrité des données entre deux applications communicantes. Le protocole est composé de deux couches : le protocole d'enregistrement TLS (TLS Record Protocol) et le protocole de poignée de main TLS (TLS Handshake Protocol). Au niveau le plus bas, superposé à un protocole de transport fiable (par exemple, TCP [TCP]), se trouve le protocole d'enregistrement TLS. Le protocole d'enregistrement TLS fournit une sécurité de connexion qui possède deux propriétés de base :

• La connexion est privée. La cryptographie symétrique est utilisée pour le chiffrement des données (par exemple, AES [AES], RC4 [SCH]). Les clés pour ce chiffrement symétrique sont générées de manière unique pour chaque connexion et sont basées sur un secret négocié par un autre protocole (tel que le protocole de poignée de main TLS). Le protocole d'enregistrement peut également être utilisé sans chiffrement.

• La connexion est fiable. Le transport de message inclut une vérification de l'intégrité du message à l'aide d'un MAC avec clé. Des fonctions de hachage sécurisées (par exemple, SHA-1, etc.) sont utilisées pour les calculs MAC. Le protocole d'enregistrement peut fonctionner sans MAC, mais n'est généralement utilisé dans ce mode que lorsqu'un autre protocole utilise le protocole d'enregistrement comme transport pour négocier les paramètres de sécurité.

Le protocole d'enregistrement TLS est utilisé pour encapsuler divers protocoles de niveau supérieur. L'un de ces protocoles encapsulés, le protocole de poignée de main TLS, permet au serveur et au client de s'authentifier mutuellement et de négocier un algorithme de chiffrement et des clés cryptographiques avant que le protocole d'application ne transmette ou ne reçoive son premier octet de données. Le protocole de poignée de main TLS fournit une sécurité de connexion qui possède trois propriétés de base :

• L'identité du pair peut être authentifiée en utilisant la cryptographie asymétrique ou à clé publique (par exemple, RSA [RSA], DSA [DSS]). Cette authentification peut être rendue optionnelle, mais est généralement requise pour au moins l'un des pairs.

• La négociation d'un secret partagé est sécurisée : le secret négocié n'est pas disponible pour les écoutes clandestines, et pour toute connexion authentifiée, le secret ne peut pas être obtenu, même par un attaquant qui peut se placer au milieu de la connexion.

• La négociation est fiable : aucun attaquant ne peut modifier la communication de négociation sans être détecté par les parties à la communication.

Un avantage de TLS est qu'il est indépendant du protocole d'application. Les protocoles de niveau supérieur peuvent se superposer sur le protocole TLS de manière transparente. Cependant, la norme TLS ne spécifie pas comment les protocoles ajoutent la sécurité avec TLS ; les décisions sur la manière d'initier la poignée de main TLS et sur la façon d'interpréter les certificats d'authentification échangés sont laissées au jugement des concepteurs et des implémenteurs des protocoles qui s'exécutent au-dessus de TLS.

1.1. Requirements Terminology (Terminologie des exigences)

Les mots-clés « MUST » (doit), « MUST NOT » (ne doit pas), « REQUIRED » (requis), « SHALL » (doit), « SHALL NOT » (ne doit pas), « SHOULD » (devrait), « SHOULD NOT » (ne devrait pas), « RECOMMENDED » (recommandé), « MAY » (peut) et « OPTIONAL » (optionnel) dans ce document doivent être interprétés comme décrit dans le RFC 2119 [REQ].

1.2. Major Differences from TLS 1.1 (Différences majeures par rapport à TLS 1.1)

Ce document est une révision du protocole TLS 1.1 [TLS1.1] qui contient une flexibilité améliorée, en particulier pour la négociation des algorithmes cryptographiques. Les changements majeurs sont :

• La combinaison MD5/SHA-1 dans la fonction pseudo-aléatoire (PRF) a été remplacée par des PRF spécifiées par suite de chiffrement. Toutes les suites de chiffrement de ce document utilisent P_SHA256.

• La combinaison MD5/SHA-1 dans l'élément signé numériquement a été remplacée par un seul hachage. Les éléments signés incluent désormais un champ qui spécifie explicitement l'algorithme de hachage utilisé.

• Nettoyage substantiel de la capacité du client et du serveur à spécifier quels algorithmes de hachage et de signature ils accepteront. Notez que cela assouplit également certaines des contraintes sur les algorithmes de signature et de hachage des versions précédentes de TLS.

• Ajout du support pour les modes de chiffrement authentifié avec données supplémentaires (authenticated encryption with additional data modes).

• Les définitions d'extensions TLS et les suites de chiffrement AES ont été fusionnées à partir de sources externes [TLSEXT] et [TLSAES].

• Vérification plus stricte des numéros de version EncryptedPreMasterSecret.

• Resserrement d'un certain nombre d'exigences.

• La longueur de verify_data dépend maintenant de la suite de chiffrement (la valeur par défaut est toujours 12).

• Description nettoyée des défenses contre les attaques Bleichenbacher/Klima.

• Les alertes doivent maintenant être envoyées dans de nombreux cas.

• Après un certificate_request, si aucun certificat n'est disponible, les clients doivent maintenant envoyer une liste de certificats vide.

• TLS_RSA_WITH_AES_128_CBC_SHA est maintenant la suite de chiffrement obligatoire à implémenter.

• Ajout de suites de chiffrement HMAC-SHA256.

• Suppression des suites de chiffrement IDEA et DES. Elles sont maintenant dépréciées et seront documentées dans un document séparé.

• Le support pour le hello compatible avec SSLv2 est maintenant un MAY (peut), et non un SHOULD (devrait), et l'envoyer est un SHOULD NOT (ne devrait pas). Le support deviendra probablement un SHOULD NOT (ne devrait pas) à l'avenir.

• Ajout d'un « fall-through » limité au langage de présentation pour permettre à plusieurs branches case d'avoir le même encodage.

• Ajout d'une section sur les pièges d'implémentation (Implementation Pitfalls).

• Les clarifications et le travail éditorial habituels.

---