Aller au contenu

Utilisateur:BernardM/TLS

Une page de Wikipédia, l'encyclopédie libre.

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

Présentation

[modifier | modifier le code]

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

En plus de la sécurité, le protocole a pour objectifs[2],[3] :

  • 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[N 2].

Architecture

[modifier | modifier le code]
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

[modifier | modifier le code]

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[5].

Une session contient les informations suivantes[6] :

  • 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[7] :

  • 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 [8] :

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

Algorithmes cryptographiques utilisés

[modifier | modifier le code]

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[9]. 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[10].

Les algorithmes suivants sont définis :

Motivations

[modifier | modifier le code]

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[19].

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[20].

Débuts de SSL

[modifier | modifier le code]

Netscape a développé la toute première version de SSL de fin 1993 à mi 1994[21]. 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[22].

Netscape passe ensuite à l'élaboration de SSLv2.

Forme moderne de SSL

[modifier | modifier le code]

Standardisation par l'IETF

[modifier | modifier le code]

Protocole d'enregistrements

[modifier | modifier le code]
É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é[23].

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[24].

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

[modifier | modifier le code]

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.

Chiffrement de flux ou absence de chiffrement
[modifier | modifier le code]
Chiffrement par bloc en mode chaîné
[modifier | modifier le code]
Chiffrement authentifié
[modifier | modifier le code]

Protocole de poignée de mains

[modifier | modifier le code]

Négociation des algorithmes cryptographiques

[modifier | modifier le code]

Authentification et échange de clé du serveur

[modifier | modifier le code]

Authentification et échange de clé du client

[modifier | modifier le code]

Fin de la poignée de mains

[modifier | modifier le code]

Reprise de session

[modifier | modifier le code]

Renégociation

[modifier | modifier le code]

Protocole d'alertes

[modifier | modifier le code]

Dérivation de clés

[modifier | modifier le code]

Interfaçage avec les protocoles de couche supérieure

[modifier | modifier le code]

Ports distincts vs négociation à la hausse

[modifier | modifier le code]

Comparaison des deux méthodes

[modifier | modifier le code]

Exemples d'utilisation de ports distincts

[modifier | modifier le code]

Exemples d'utilisation de négociation à la hausse

[modifier | modifier le code]

Tunnels SSL

[modifier | modifier le code]

Implémentations

[modifier | modifier le code]
  1. La suite de cet article utilise uniquement le terme TLS, conformément à l'appellation standard actuelle.
  2. Seule l'extension algorithmes de signature est définie dans la RFC 5246[4].
  3. a et b L'utilisation des courbes elliptiques avec TLS est décrite dans la RFC 4492[11].
  4. L'utilisation de SRP avec TLS est décrite dans la RFC 5054[12].
  5. L'utilisation de Kerberos avec TLS est décrite dans la RFC 2712[13].
  6. L'utilisation d'une clé pré-partagée avec TLS est décrite dans les RFC 4279[14] et la RFC 4785[15].
  7. L'utilisation de Camellia avec TLS est décrite dans la RFC 5932[16].
  8. L'utilisation d'ARIA avec TLS est décrite dans la RFC 6209[17].
  9. L'utilisation de SEED avec TLS est décrite dans la RFC 4162[18].

Références

[modifier | modifier le code]

Bibliographie

[modifier | modifier le code]
  • (en) Eric Rescorla, SSL and TLS : Designing and Building Secure Systems, Addison Wesley, , 530 p. (ISBN 0-201-61598-3)
  • (en) Rolf Oppliger, SSL and TLS : Theory and Practice, Artech House, , 279 p. (ISBN 978-1-59693-447-1[à vérifier : ISBN invalide])
  • (en) William Stallings, Cryptography and Network Security : Principles and Practice, Pearson, , 744 p. (ISBN 978-81-317-6166-3)
  • (en) Tim Dierks et Eric Rescorla, The Transport Layer Security (TLS) Protocol Version 1.2 : RFC 5246, , 104 p.
  • (en) Donald Eastlake, Transport Layer Security (TLS) Extensions: Extension Definitions : RFC 6066, , 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, , 35 p.
  • (en) Hyangjin Lee, Jaeho Yoon et Jaeil Lee, Addition of SEED Cipher Suites to Transport Layer Security (TLS) : RFC 4162, , 6 p.
  • (en) David Taylor, Tom Wu, Nikos Mavrogiannopoulos et Trevor Perrin, Using the Secure Remote Password (SRP) Protocol for TLS Authentication : RFC 5054, , 24 p.
  • (en) Ari Medvinsky et Matthew Hur, Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) : RFC 2712, , 7 p.
  • (en) Pasi Eronen et Hannes Tschofenig, Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) : RFC 4279, , 15 p.
  • (en) Uri Blumenthal et Purushottam Goel, Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) : RFC 4785, , 5 p.
  • (en) Akihiro Kato, Masayuki Kanda et Satoru Kanno, Camellia Cipher Suites for TLS : RFC 5932, , 6 p.
  • (en) Joseph Salowey, Abhijit Choudhury et David McGrew, AES Galois Counter Mode (GCM) Cipher Suites for TLS : RFC 5288, , 8 p.
  • (en) Mohamad Badra, Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode : RFC 5487, , 7 p.
  • (en) Eric Rescorla, TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM) : RFC 5488, , 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, , 9 p.
  • (en) Eric Rescorla, Marsh Ray, Steve Dispensa et Nasko Oskov, Transport Layer Security (TLS) Renegotiation Indication Extension : RFC 5746, , 15 p.
  • (en) Scott Hollenbeck, Transport Layer Security Protocol Compression Methods : RFC 3749, , 8 p.
  • (en) Nikos Mavrogiannopoulos et Daniel Gillmor, Using OpenPGP Keys for Transport Layer Security (TLS) Authentication : RFC 6091, , 9 p.

Articles connexes

[modifier | modifier le code]