Sartomiki.net

Le protocole
Le Transport Layer Security layer (TLS) est un protocole de cryptographie qui permet la communication sécurisée  entre deux terminales sur un réseau de type TCP/IP. Le protocole TLS v.1.2 a été standardisé en 2008 dans le RFC 5246  sur la base du Secure Sockets Layer (SSL).

Les objectifs principaux du protocole TLS sont :
-la création d’un canal sécurisé entre deux hôtes ;
-l’interopérabilité entre deux applications différentes qui utilisent le protocole TLS ;
-l’intégration des nouveaux systèmes de sécurisation ;
-la garantie des prestations acceptables pour les opérations de cryptographie.

Le protocole TLS crée une connexion sécurisée indépendant du protocole applicatif utilisé : les couches supérieures peuvent utiliser cette interface sécurisée sans se préoccuper de gérer individuellement les problèmes de sécurité. TLS est, au moment, utilisé pour encapsuler nombreux protocoles applicatives comme HTTP, FTP, SMTP et beaucoup d’autres. TLS est utilisé principalement avec TCP, mais existe une variante, qui s’appelle « Datagram Transport Layer Security » (DTLS), pour l’utiliser avec UDP.

Le protocole est composé essentiellement par deux niveaux : le niveau plus bas (TLS Record) est relié directement au protocole de transport (TCP ou autres) et le niveau plus haut (TLS handshake) s’occupe de la communication sécurisée.

Le protocole TLS Record assure que la connexion soit privée, en utilisant une cryptographie symétrique , et fiable, en utilisant une signature .

Le protocole TLS Handshake permet l’authentification entre les deux hôtes, la négociation des algorithmes de cryptographie et le choix des clés.

Chacun des hôtes peut être authentifié avec un algorithme d’authentification asymétrique . La négociation des secrets communs est sécurisée et, en plus, la communication est fiable ; ca veut dire que personne ne peut modifier les paramètres de communication sans être découvert.

La négociation des paramètres qui permet la création d’un canal sécurisé entre un client et un serveur est faite comme suit :
1.    Le client présente la liste des algorithmes de chiffrement et d’hash qu’il peut utiliser ;
2.    Le serveur décide quels algorithmes utiliser et réponde au client. En plus, le serveur envoie un certificat qui contient le nom du serveur, la signature d’une entité certificatrice et la clé publique du serveur;
3.    Le client vérifie le certificat du serveur et confirme les paramètres. En plus, le client extrait un nombre aléatoire qui est envoyé au serveur crypté avec sa clé publique.
4.    A partir du nombre aléatoire le serveur et le client dérivent les clés de chiffrement et de déchiffrement. La session d’échange de données cryptées peut maintenant commencer.

Optionnellement, dans la phase « 2 », le serveur peut demander au client de lui fournir son certificat. Un message de « Certificate Request » est envoyé au client. Avec cette procédure aussi le client est authentifié auprès du serveur et nous pouvons parler d’authentification mutuelle.

Renégociation TLS
En général, si un des deux hôtes qui participent au dialogue a la nécessité de changer un ou plus paramètres de la connexion,  il peut faire la requête d’une renégociation TLS. Cette requête est faite avec un message de type « Hello Request » ou « Client Hello ». L’opération se déroule avec les phases typiques de la première négociation, déjà décrit dans la partie précédente. Après la renégociation, la session va continuer de façon transparente pour l’utilisateur et pour la couche applicative.

La renégociation est une pratique très utilisée pour exigences d’interopérabilité, de flexibilité et de sécurité. TLS donne la possibilité de fournir à l’interlocuteur une liste d’algorithmes différents, si que les deux hôtes vont en choisir un. Par exemple, si un des deux hôtes change ses capacité computationnels (nous pouvons penser à un dispositif mobile qui peut marcher avec ou sans l’alimentation du réseau électrique), le protocole TLS peut changer l’algorithme de chiffrement utilisé pour mieux balancer les exigences de sécurité et les problèmes de power consumption.

Après un certain temps, quand une certaine quantité de données a été échangés entre les deux hôtes, c’est toujours conseillé de changer la clé de session. Cette opération est nécessaire pour éviter qu’un possible attaquant puisse découvrir la clé de session, en analysant les paquets, ou rejouer des messages. Pour éviter ce problème, soit le client, soit le serveur peuvent demander à la couche TLS de renégocier les paramètres de session. En effet, une renégociation, aussi quand ne change pas les protocoles de communication, force la mise à jour de la clé de session.

C’est important souligner que la renégociation d’une session active est mise en place à l’intérieur de la session existante et que, donc, toutes les négociations successives à la première sont cryptées dans la même manière de tous les autres messages applicatifs.

Problèmes de la renégociation
Comme nous avons dit, la phase de renégociation est fondamentale pour le bon fonctionnement du protocole TLS, mais il crée une discontinuité dans la session active. Cette discontinuité, comme dans le cas de notre étude, peut représenter un problème et permettre attaques de diffèrent type.

En plus, nous avons analysé la procédure de requête d’un certificat au client, méthode qui est disponible optionnellement en TLS. Avant le patch, qui a été standardisé avec le RFC 5746 , le serveur web acceptait la requête de connexion TLS d’un client et, après avoir reçu la requête HTTP, si était le cas, procédait avec une renégociation pour demander l’envoie du certificat. Aussi si les échanges étaient sécurisés, le problème de discontinuité est évident : une nouvelle session, théoriquement plus « secoure » que la première (à cause de l’authentification supplémentaire donné par le certificat du client),  était crée a partir d’une requête moins secoure.

Comme déjà dit, tous les échanges d’une renégociation TLS sont sécurisés par la première négociation TLS, mais ça n’empêche pas la possibilité à un possible attaquant de jouer le rôle de MITM, pour crypto-analyser ou essayer de modifier les messages qui sont échangé. La renégociation de session est une procédure efficace contre ce type d’attaque, s’il est utilisé correctement. L’absence d’un canal direct de communication entre la couche TLS et la couche application a obligé les développeurs à utiliser la renégociation pour gérer des cases, qui n’étaient pas pensés au moment de son introduction. C’est clair que la présence d’une procédure de ce type donne la possibilité d’exploiter différentes vulnérabilités.

Un autre problème est représenté par le temps perdu, en effectuent cette opération. En effet, la renégociation est effectué surtout par mettre à jour la clé de session, mais dans ce cas là est nécessaire renégocier aussi les autres paramètres de la session, en génèrent des paquets inutiles.

Pour résoudre ce problème, a été mise un place un système, appelé Session Resumption. Pour le comprendre, il faut considérer que chaque négociation TLS est identifiée par un Session ID. La Session Resumption permit à un hôte de spécifier le numéro d’une session déjà utilisée pour utiliser les mêmes paramètres de cryptographie une autre fois et sauver quelques cycles de CPU. Cette méthode a été pensée pour optimiser la communication, mais apporte des problèmes de sécurité et il représente une potentielle vulnérabilité liée à la renégociation.