Utilisateur:BernardM/TLS

Transport Layer Security (TLS), nommé Secure Sockets Layer (SSL) avant sa normalisation par l'IETF, est un protocole de sécurisation de connexion réseau.

Présentation

Le protocole TLS sert à sécuriser une connexion réseau en apportant les services suivants :

• confidentialité : les données à protéger sont chiffrées ;
• authentification : il est possible d'authentifier le serveur et le client ;
• intégrité.

En plus de la sécurité, le protocole a pour objectifs :

• l'interopérabilité : des implémentations peuvent être développées indépendamment ;
• l'extensibilité : TLS permet notamment l'utilisation d'extensions, permettant d'ajouter des fonctionnalités sans avoir à modifier le protocole lui-même ;
• l'efficience : un mécanisme de cache de session évite d'avoir à répéter certains calculs lourds ;
• la spontanéité : l'utilisation se fait automatiquement par le client, sans intervention manuelle ;
• la transparence : les protocoles sécurisés n'ont pas ou peu à être modifiés pour être utilisés avec TLS.

Emplacement de TLS dans la pile TCP/IP

TLS s'intercale entre une couche de transport fiable (typiquement TCP) et la couche application, et protège cette dernière. Une variante de TLS, appelée DTLS (Datagram TLS) a été conçue pour une utilisation sur une couche de transport non-fiable (telle que UDP).

Pour sécuriser les échanges, TLS combine différents types d'algorithmes cryptographiques. Le serveur et, optionnellement, le client sont authentifiés via des certificats X.509. Un établissement de clés entre les deux parties leur permet de générer un grand nombre aléatoire en commun appelé secret maître, connu d'elles seules. Ce dernier sert à initialiser un générateur de nombres pseudo-aléatoires, grâce auquel sont construites les clés secrètes utilisées pour chiffrer et authentifier une session TLS. Les données sont cryptées par des algorithmes de chiffrement symétriques. Leur intégrité est vérifiée au moyen de codes d’authentification de message. TLS contient un mécanisme permettant au serveur et au client de négocier le choix des algorithmes à utiliser, ainsi que les paramètres de ces algorithmes (tailles des clés, mode d'opération, etc).

Le protocole TLS est défini dans la RFC 5246. Les extensions sont majoritairement définies dans d'autres RFC.

Architecture

Pile des protocoles de TLS

Le protocole TLS est composé de deux couches de protocoles. La couche basse est constituée du protocole d'enregistrements. Elle permet de transporter et sécuriser les couches supérieures, qui sont :

• le protocole de poignée de mains ;
• le protocole d'alertes ;
• le protocole de changement de spécification d'algorithmes ;
• la couche applicative qui doit être protégée par TLS.

Le protocole de poignée de mains sert à négocier les algorithmes cryptographiques à utiliser et à choisir leurs paramètres et les clés secrètes qui y sont associées, ainsi qu'à procéder à l'établissement de clés secrètes. Le protocole d'alertes permet d'avertir d'un problème rencontré au niveau du protocole TLS, ainsi qu'à clore une connexion. Le protocole de changement de spécification d'algorithmes indique que les enregistrements suivants seront protégés par les algorithmes cryptographiques négociés lors de la poignée de mains.

Notion de session

La poignée de mains peut être très coûteuse en terme de ressources aussi bien processeur, à cause des calculs de cryptographie asymétrique, que réseau, à cause des nombreux messages à échanger. Pour parer à ce problème, TLS prévoit la possibilité, pour un serveur et un client donnés, de n'établir les paramètres cryptographiques qu'une seule fois et de les réutiliser à plusieurs reprises. Pour cela, une distinction est faite entre session et connexion. Une session est établie après une poignée de mains complète, et contient les choix des algorithmes et le secret maître. Une connexion correspond à un échange de données spécifique (connexion TCP) et contient les algorithmes et les clés secrètes.

Une session contient les informations suivantes :

• identifiant de session : choisi par le serveur, servant à identifier une session à restaurer ;
• certificat du pair : certificat X.509v3 ;
• algorithme de compression ;
• algorithmes cryptographiques ;
• secret maître ;
• reprise possible : drapeau indiquant si la session peut reprendre.

Une connexion contient les paramètres de sécurité suivants :

• extrêmité de connexion : rôle de la machine (serveur ou client) ;
• algorithme de compression ;
• algorithmes cryptographiques ;
• secret maître ;
• nombre aléatoire du client ;
• nombre aléatoire du serveur.

Une connexion contient égalements les paramètres d'état suivants, qui doivent être tenus à jour pour chaque enregistrement  :

• état de compression ;
• état de chiffrement ;
• clé de MAC ;
• numéro de séquence.

Algorithmes cryptographiques utilisés

TLS donne le choix entre de nombreux algorithmes, avec différents paramètres. Cependant les ensembles d'algorithmes négociés par le client et le serveur sont établis par une liste de combinaisons d'algorithme d'authentification, d'échange de clés, de chiffrement, de hachage, prédéfinie par la norme, ce qui empêche de garantir que toutes les combinaisons soient possibles. Pour respecter la norme TLS 1.2, une application doit, au minimum, gérer la combinaison constituée de RSA, AES avec clé de 128 bits en mode CBC, et SHA-1.

Les algorithmes suivants sont définis :

• authentification : RSA, DSA, ECDSA, SRP, anonyme (pas d'authentification) ;
• échange de clés : RSA, Diffie-Hellman (DH), DH éphémère (DHE), ECDH, ECDH éphémère (ECDHE), Kerberos, clé pré-partagée ;
• chiffrement : RC4, 3DES-EDE, AES avec clé de 128 ou 256 bits, Camellia avec clé de 128 ou 256 bits, ARIA avec clé de 128 ou 256 bits, SEED ;
• mode d'opération de chiffrement par bloc : CBC, GCM ;
• hachage : MD5, SHA-1, SHA-2 avec condensat de 224, 256, 384 ou 512 bits.

Historique

Motivations

Le protocole SSL a été inventé par l'entreprise américaine Netscape. Le commerce électronique, sous sa forme la plus courante le paiement par carte de crédit, commençait à se développer et ses acteurs étaient soucieux de le sécuriser. Il fallait apporter de la confidentialité en empêchant quiconque d'observer les échanges entre client et commerçant, permettre au client de s'assurer de l'authenticité de son interlocuteur sans que la réciproque ne soit nécessaire (le numéro de carte du client étant suffisant pour la commerçant), et permettre au client une utilisation simple sans démarche préalable. Le besoin était donc de sécuriser le Web, donc le protocole HTTP. Cependant SSL a été créé pour être transparent pour toute application fonctionnant sur une couche de transport fiable.

Le nom choisi pour ce protocole est Secure Socket Layer, soit « couche de sockets sécurisée ». L'objectif du protocole étant d'avoir une utilisation similaire à celle des sockets TCP.

Débuts de SSL

Netscape a développé la toute première version de SSL de fin 1993 à mi 1994. Elle comportait d'importants défauts. Elle n'assurait pas l'intégrité des messages, et, utilisant l'algorithme de chiffrement de flux RC4, elle permettait à un attaquant de faire des changements prédictibles sur le texte en clair. Elle ne comportait pas non plus de numéros de séquence et était donc vulnérable à une attaque par rejeu. Les numéros de séquence seront ajoutés plus tard, ainsi qu'une somme de contrôle, mais en utilisant un contrôle de redondance cyclique (CRC), qui n'était ni irréversible, ni résistant aux collisions. Netscape n'a jamais rendu publique une spécification ou une implémentation de SSLv1.

Netscape passe ensuite à l'élaboration de SSLv2.

Protocole

Protocole d'enregistrements

Étapes du traitement des enregistrements

Les données à transporter sont d'abord découpées en fragments d'une taille maximale de 16384 octets, afin de pouvoir traiter les données au fur et à mesure qu'elles arrivent. Cela permet en particulier de ne pas avoir à attendre la fin des données pour vérifier leur intégrité.

Les fragments sont ensuite optionnellement compressés en utilisant l'algorithme choisi pendant la poignée de mains. TLS donne la possibilité de compresser les données, car une fois chiffrées elle seront très peu compressibles puisque le but du chiffrement est précisément d'avoir un aspect le plus aléatoire possible.

Les fragments sont alors chiffrés et authentifiés selon les algorithmes choisis pendant la poignée de mains. Le détail des modalités de cette opération dépend des types d'algorithmes mis en œuvre.

Enfin les données ainsi protégées sont préfixées par l'en-tête du protocole d'enregistrements.

Protection de la charge utile

TLS distingue trois cas de figures pour le chiffrement et l'authentification des données, qui sont traités par trois structures de données différentes.

Interfaçage avec les protocoles de couche supérieure

Annexes

Bibliographie

• (en) Eric Rescorla, SSL and TLS : Designing and Building Secure Systems, Addison Wesley, mars 2001, 530 p. (ISBN 0-201-61598-3)
• (en) Rolf Oppliger, SSL and TLS : Theory and Practice, Artech House, 11 août 2009, 279 p. (ISBN 978-1-59693-447-1^{[à vérifier : ISBN invalide]})
• (en) William Stallings, Cryptography and Network Security : Principles and Practice, Pearson, 2011, 744 p. (ISBN 978-81-317-6166-3)

RFC

• (en) Tim Dierks et Eric Rescorla, The Transport Layer Security (TLS) Protocol Version 1.2 : RFC 5246, août 2008, 104 p.
• (en) Donald Eastlake, Transport Layer Security (TLS) Extensions: Extension Definitions : RFC 6066, janvier 2011, 25 p.
• (en) Simon Blake-Wilson, Nelson Bolyard, Vipul Gupta, Chris Hawk et Bodo Moeller, Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) : RFC 4492, mai 2006, 35 p.
• (en) Hyangjin Lee, Jaeho Yoon et Jaeil Lee, Addition of SEED Cipher Suites to Transport Layer Security (TLS) : RFC 4162, août 2005, 6 p.
• (en) David Taylor, Tom Wu, Nikos Mavrogiannopoulos et Trevor Perrin, Using the Secure Remote Password (SRP) Protocol for TLS Authentication : RFC 5054, novembre 2007, 24 p.
• (en) Ari Medvinsky et Matthew Hur, Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) : RFC 2712, octobre 1999, 7 p.
• (en) Pasi Eronen et Hannes Tschofenig, Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) : RFC 4279, décembre 2005, 15 p.
• (en) Uri Blumenthal et Purushottam Goel, Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) : RFC 4785, janvier 2007, 5 p.
• (en) Akihiro Kato, Masayuki Kanda et Satoru Kanno, Camellia Cipher Suites for TLS : RFC 5932, juin 2010, 6 p.
• (en) Joseph Salowey, Abhijit Choudhury et David McGrew, AES Galois Counter Mode (GCM) Cipher Suites for TLS : RFC 5288, août 2008, 8 p.
• (en) Mohamad Badra, Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode : RFC 5487, mars 2009, 7 p.
• (en) Eric Rescorla, TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM) : RFC 5488, août 2008, 6 p.
• (en) Woo-Hwan Kim, Jungkeun Lee, Je-Hong Park et Daesung Kwon, Addition of the ARIA Cipher Suites to Transport Layer Security (TLS) : RFC 6209, avril 2011, 9 p.
• (en) Eric Rescorla, Marsh Ray, Steve Dispensa et Nasko Oskov, Transport Layer Security (TLS) Renegotiation Indication Extension : RFC 5746, février 2010, 15 p.
• (en) Scott Hollenbeck, Transport Layer Security Protocol Compression Methods : RFC 3749, mai 2004, 8 p.
• (en) Nikos Mavrogiannopoulos et Daniel Gillmor, Using OpenPGP Keys for Transport Layer Security (TLS) Authentication : RFC 6091, février 2011, 9 p.

Articles connexes

• Cryptographie symétrique
• Cryptographie asymétrique
• Certificat électronique