Introduction aux concepts de TLS (1/3)

Azmi Sbai Etude - Recherche

Présentation de TLS:

Secure Socket Layer (SSL) est un protocole mis au point par Netscape à partir de 1994 qui permet l’établissement d’une connexion sécurisée (chiffrée, intègre et authentifiée). La version 3 date de 1995 et est la dernière en date. Transport Layer Security (TLS) est la nouvelle version de SSL depuis le rachat par l’Internet Engeneering Task Force (IETF).

SSL/TLS se situe au dessus de la couche transport du modèle TCP/IP, il présente donc l’avantage d’être transparent pour les applications, comme HTTP (web client) ou SMTP (mail) par exemple. Il permet de chiffrer des données, d’assurer l’intégrité d’un message et d’authentifier un client ou un serveur via l’utilisation des certificats X509.

La principale différence entre SSL et TLS est que ce dernier utilise des algorithmes de chiffrement plus fort et qu’il peut supporter plusieurs extensions. SSL/TLS utilise le chiffrement à clé publique pour l’authentification et le chiffrement symétrique pour l’échange de donnée.

Le protocole TLS est formé par 4 sous protocoles :

  1. Protocole Handshake
  2. Protocole Record
  3. Protocole Change Cipher Spec (CCS)
  4. Protocole Alert

Architecture du protocole SSL/TLS

Protocole Handshake:

C’est le protocole qui régit l’établissement d’une connexion entre deux entités d’un réseau. Il gère l’authentification du serveur et/ou du client, la négociation des algorithmes de chiffrement et la génération des clés symétriques. Ci-dessous un schéma représentatif de la séquence des différents messages échangés.

Protocole Handshake

1. ClientHello: le client initie une requête en envoyant un message de type ClientHello qui contient:

  • Version: la plus haute version de SSL/TLS que puisse utiliser le client;
  • Random: un horodatage de 32 bits et une valeur aléatoire de 28 octets générée par le client qui sera utilisée pour la dérivation des clés;
  • CipherSuite: une liste, par ordre décroissant de préférence, des suites cryptographiques que supporte le client;
  • Session ID: un nombre, qui identifie la connexion; (optionnel)
  • Extensions: les différentes extensions TLS supportées par le client: Server Name Indication (SNI), Signed Certificate Timestamp (SCT), Encrypt_then_MAC…

2. ServerHello: le serveur répond au client avec un message de type ServerHello qui contient:

  • Version: la plus haute version de SSL/TLS que puisse utiliser le serveur;
  • Random: un horodatage de 32 bits et une valeur aléatoire de 28 octet;
  • Session ID: l’identifiant de la session qui débute définie par le serveur;
  • CipherSuite: la suite cryptographique retenue pour la session. Le serveur sélectionne la première suite qu’il connaît dans la liste transmise par le client;
  • Extensions: les différentes extensions TLS supportées par le serveur: FALLBACK_SCSV, Encrypt_then_MAC.

3. ServerCertificate (recommandé): le serveur envoie son certificat X509 qui contient des informations sur sa clé publique.

4. ServerKeyExchange (recommandé): le serveur transmet dans un message ServerKeyExchange un paramètre d’échange éphémère qu’il signe à l’aide de sa clé privée (lors de l’échange des clés basé sur RSA cette étape est optionnel).

5. ServerHelloDone: le serveur indique qu’il attend une réponse du client.

6. ClientKeyExchange: après vérification du certificat du serveur et de la valeur précédente, le client génère de son côté une valeur éphémère qui servira à produire les clés utilisées par la suite: Dans le cas de RSA cette clé est envoyée au serveur chiffré à l’aide de sa clé publique. Dans le cas du DH cette clé est envoyée au serveur chiffré avec sa clé privé. À l’aide de ce secret partagé, le serveur et le client génèrent quatre clés pour la session qui ne sont pas échangées.

7. ChangeCipherSpec: le client signale l’adoption de la suite négociée avec le serveur.

8. Finished: les paramètres cryptographiques et de sécurité ont été bien pris en compte. Ce message est chiffré et signé avec les clés calculées précédemment.

Protocole Record:

C’est le protocole qui gère la transmission des données chiffrées sous une forme homogène en les en-capsulant, il a pour objectifs:

  • Confidentialité: assure que le contenu du message ne puisse pas être lu par un tiers : les données sont chiffrées en utilisant les clés produites lors de la négociation.
  • Intégrité et Authenticité:  permet de vérifier la validité des données transmises, grâce aux signatures HMAC : cette signature est elle aussi générée à l’aide des clés produites lors de la négociation.
  • Encapsulation:  permet aux données SSL/TLS d’être transmises de manière normalisé et reconnues sous une forme homogène.

Les étapes du processus d’encapsulation du protocole Record sont les suivantes:

  1. Segmentation: les données sont découpées en blocs de taille inférieure à 16 ko;
  2. Compression: les données sont compressées en utilisant l’algorithme choisi lors de la négociation. \’A noter: à partir de SSL v3.0, il n’y a plus de compression;
  3. Signature MAC: une signature des données est générée à l’aide de la clé MAC (dans le cas de l’utilisation de l’extension MAC_then_encrypt);
  4. Chiffrement: le paquet obtenu est chiffré à l’aide de la fonction définie lors de la négociation et de la key.encryption;
  5. Ajout de l’en-tête: l’en-tête SSL/TLS est ajouté et le paquet est passé à la couche inférieure. Il contient:
  • Content-Type: indique le type de paquet SSL et TLS contenu dans l’enregistrement;
  • Major Version, Minor Version: numéros de version du protocole SSL/TLS utilisé;
  •  Length: taille du fragment SSL et TLS.

Processus d’encapsulation du protocole Record

À la réception des paquets, le destinataire vérifie l’en-tête du paquet, le déchiffre, vérifie le champ HMAC et rassemble les différents blocs.

Protocole Change Cipher Spec:

Ce protocole contient un seul message de 1 octet ChangeCipherSpec et permet de modifier les algorithmes de chiffrement et établir de nouveaux paramètres de sécurité. Il indique au protocole Record le changement des suites cryptographiques.

Protocole Alert:

Ce protocole est utilisé pour les messages d’erreurs que peuvent s’envoyer aux clients et serveurs. Il y a deux sortes de message d’alerte:

  • Les fatal error: entraîne l’arrêt de la connexion
  • Les warning: indique une connexion instable

 

Nous verrons dans un prochain article, comment fonctionne les suites cryptographiques et la distribution des certificats dans le cas d’une PKI mondiale.