Sécuriser vos communications en ligne : tout ce qu'il faut savoir sur SSL/TLS

Dans un monde de plus en plus connecté, la sécurité des communications en ligne est devenue un enjeu crucial. Le protocole TLS (Transport Layer Security) joue un rôle essentiel dans la protection de nos échanges sur le web.

Lorsque nous naviguons sur internet, nos données transitent à travers de nombreux réseaux avant d'atteindre leur destination finale. Sans protection, ces informations sont vulnérables aux interceptions et aux manipulations par des tiers malveillants.

Le protocole TLS permet de résoudre ces problèmes en offrant trois garanties :

La confidentialité : les données ne sont accessibles que par les utilisateurs autorisés ;
L’intégrité : garantit que les informations n’ont pas été altérées sur le réseau ;
L'authentification : confirme l’authenticité du serveur ou du client.

L'objectif principal de TLS est d'établir une connexion sécurisée entre deux parties, sans configuration ou échange préalable de clés, et ce même si le canal de communication initial n'est pas sécurisé et peut être écouté par des tiers malveillants.

I. SSL ou TLS ?

SSL a été développé par Netscape et a connu plusieurs versions (SSL 1.0, 2.0, 3.0). TLS est la version améliorée et standardisée de SSL, développée par l'IETF (Internet Engineering Task Force). Les versions actuelles sont TLS 1.0, 1.1, 1.2 et 1.3. SSL n'est plus recommandé pour une utilisation moderne en raison de ses failles de sécurité connues. TLS est largement adopté et supporté par la plupart des navigateurs et serveurs web actuels. Pour garantir la sécurité des échanges, il est aujourd’hui recommandé d’utiliser TLS version 1.2 ou supérieure.

TLS est normalement implémenté au-dessus de TCP afin de chiffrer les protocoles de la couche Application tels que HTTP, FTP, SMTP ou encore IMAP. Il peut également être implémenté sur d'autres protocoles, par exemple UDP, connu sous le nom de Datagram Transport Layer Security (DTLS).

Le protocole TLS permet de négocier dynamiquement les algorithmes cryptographiques à utiliser (cipher suites) lors de l’établissement d'une session sécurisée entre un client et un serveur. Le serveur peut (et doit) restreindre la liste des suites de chiffrement disponibles en interdisant les suites de chiffrement considérées comme obsolètes ou peu sécurisées afin de garantir un niveau de sécurité acceptable en fonction du cas d’usage.

Une suite de chiffrement se compose de trois composants :

Un algorithme d'échange de clés (p. ex. Diffie-Hellman, RSA) pour établir une clé symétrique partagée de manière sécurisée ;
Un algorithme de chiffrement symétrique (p. ex. AES, ChaCha20) pour assurer la confidentialité des données échangées ;
Un algorithme de hachage ou une fonction d'authentification de message (p. ex. SHA-256) afin d'assurer l'intégrité et l'authenticité des messages.

II. Cryptographie symétrique vs asymétrique

TLS utilise une combinaison de cryptographie symétrique et asymétrique, car cela offre un bon compromis entre performances et sécurité.

Avec la cryptographie symétrique, également appelée cryptographie à clé secrète, une seule clé de chiffrement est utilisée pour à la fois chiffrer et déchiffrer les données. Cette clé doit être partagée de manière sécurisée entre l'expéditeur et le destinataire avant toute communication. Les algorithmes symétriques comme AES, DES ou Blowfish sont généralement très rapides et efficaces, ce qui les rend particulièrement adaptés au chiffrement de grands volumes de données. Cependant, la gestion et la distribution sécurisée de la clé secrète peuvent s'avérer complexes.

À l'inverse, la cryptographie asymétrique, ou cryptographie à clé publique, utilise une paire de clés mathématiquement liées : une clé publique et une clé privée. Il est possible de chiffrer et déchiffrer avec les deux clés :

Tout ce qui a été chiffré avec la clé publique peut être déchiffré uniquement avec la clé privée ;
Et inversement, tout ce qui a été chiffré avec la clé privée peut être déchiffré uniquement avec la clé publique.

La clé publique peut être diffusée librement à tous les correspondants, tandis que la clé privée doit être conservée de manière sécurisée par son propriétaire. Cette approche résout le problème de la distribution de la clé, car il n'est plus nécessaire de partager une clé secrète. De plus, la cryptographie asymétrique permet l'authentification des utilisateurs et des serveurs grâce à l'utilisation de certificats numériques. Cependant, les algorithmes asymétriques comme RSA ou l’ECC (Elliptic Curve Cryptography) sont généralement plus lents que les algorithmes symétriques, les rendant moins adaptés au chiffrement de grandes quantités de données.

En pratique, les deux approches sont souvent utilisées de manière complémentaire. La cryptographie symétrique est employée pour le chiffrement des données, tandis que la cryptographie asymétrique sert à la gestion sécurisée des clés de chiffrement symétrique, ainsi qu'à l'authentification des parties communicantes. Cette combinaison permet d'obtenir à la fois la rapidité de la cryptographie symétrique et la flexibilité de la cryptographie asymétrique, offrant ainsi une solution de sécurité robuste et efficace.

III. Établissement d’une connexion sécurisée

Cette section présente une introduction à l’établissement d’une connexion sécurisée ainsi que les problèmes à résoudre. L’idée de cette section est de reconstruire pas à pas les fonctionnalités du protocole TLS, afin de bien comprendre les différentes étapes du protocole et les problèmes auxquels elles répondent.

Version 1 : clé asymétrique

La version la plus simple consiste à n’utiliser qu’une paire de clés asymétriques (RSA par exemple) sur le serveur. Lorsqu’un client envoie une requête au serveur, il la chiffre avec la clé publique du serveur. Dans la mesure où seul le serveur est en possession de la clé privée, il est le seul à pouvoir déchiffrer la requête envoyée par le client. En revanche, lorsque le serveur va envoyer la réponse, un problème se pose : il peut soit l’envoyer en clair, soit la chiffrer avec sa clé privée. Les deux cas sont en réalité identiques du point de vue de la sécurité puisque tout le monde peut récupérer la clé publique et donc déchiffrer la réponse. Cette méthode garantit la confidentialité uniquement dans un sens : du client vers le serveur.

Version 2 : clé asymétrique et clé symétrique

Pour obtenir une communication chiffrée dans les deux sens, on peut utiliser la cryptographie symétrique. Mais comment le client et le serveur peuvent-ils se retrouver en possession d’une même clé symétrique éphémère sans jamais l’envoyer en clair sur le réseau ?

Une manière simple de le faire est d’utiliser la paire de clés RSA évoquée dans la solution précédente :

Le client récupère la clé publique du serveur ;
Le client génère un “pre-master password” de manière aléatoire ;
Le client chiffre le “pre-master password” avec la clé publique du serveur et l’envoie au serveur ;
Le serveur déchiffre le “pre-master password” avec sa clé privée ;
Le client et le serveur se retrouvent en possession d’un même secret. Chacun de leur côté, ils vont pouvoir dériver une même clé symétrique à partir du “pre-master password”.

Cette méthode garantit la confidentialité des échanges dans les deux sens.

En revanche, elle ne permet pas de garantir l’authenticité du serveur. En effet, si un attaquant réussit à se positionner entre le client et le serveur via une attaque Man-In-The-Middle (MITM), il peut faire proxy en générant lui-même sa propre paire de clés asymétriques.

Le client, pensant communiquer avec un serveur légitime, va en réalité établir une connexion chiffrée (confidentielle) avec le proxy de l’attaquant. L’attaquant peut donc déchiffrer le trafic du client, éventuellement le modifier avant de le transférer au serveur légitime, et ce, sans que le client puisse le détecter !

IV. Vérification de l’authenticité du serveur

Comme vu précédemment, lorsqu’un utilisateur se connecte à un site sécurisé via TLS, il veut être certain qu’il communique avec le bon serveur et non avec un imposteur. C'est là qu'interviennent les certificats numériques qui reposent sur le standard X.509.

Le rôle des certificats dans TLS

Le protocole TLS (Transport Layer Security) vise non seulement à chiffrer les données échangées, mais aussi à authentifier l'identité du serveur. Pour qu'un client puisse valider qu'il communique avec un serveur légitime, le serveur présente un certificat numérique. Ce certificat contient la clé publique du serveur ainsi que des informations sur celui-ci, comme son nom de domaine, contenu dans le champ DN (Distinguished Name) ou SAN (Subject Alternative Names), et signé par une autorité de certification (CA).

Qu'est-ce qu'une Autorité de Certification (CA) ?

Une Autorité de Certification est une entité de confiance qui émet des certificats conformes au standard X.509. En signant numériquement le certificat d'un serveur, la CA garantit aux clients que la clé publique appartient bien à l'entité revendiquée et que celle-ci contrôle le domaine en question. On parle alors de « chaîne de confiance » : le certificat du serveur a été émis par une CA de confiance, qui elle-même se fonde sur une hiérarchie démarrant par un certificat racine.

La chaîne de confiance

Les certificats racines sont préinstallés dans les systèmes d'exploitation ou dans les navigateurs. Ils constituent le point de départ de toute la chaîne de confiance.

Pour protéger le certificat racine, il est courant que les certificats serveurs soient signés par une autorité de certification intermédiaire. Ces certificats intermédiaires héritent ainsi de la confiance liée au certificat racine qui les signe.

Le certificat « feuille », remis par le serveur au client lors de la connexion TLS, est signé par une CA intermédiaire et contient la clé publique et les informations d'identité du serveur.

En utilisant ce système de certificats, on peut donc utiliser la méthode décrite au paragraphe 3.2 pour établir une connexion sécurisée tout en contrant une attaque MITM, car on a la possibilité de vérifier l’authenticité de la clé publique envoyée par le serveur. Cette authenticité repose sur les vérifications effectuées par les autorités de certification avant de délivrer un certificat.

V. La confidentialité persistante

Le problème de confidentialité persistante

Lors de l’établissement d’une connexion sécurisée avec TLS, il est possible d’utiliser plusieurs algorithmes d'échange de clés :

RSA,
Diffie-Hellman (DH),
Ephemeral Diffie-Hellman (DHE),
Elliptic Curve Diffie-Hellman (ECDH),
Ephemeral Elliptic Curve Diffie-Hellman (ECDHE).

L’exemple précédent utilisait RSA comme algorithme d’échange de clés, mais il n’est plus recommandé en termes de sécurité. En effet, en utilisant RSA, on utilise la clé privée du serveur pour chiffrer le “pre-master password” qui permet de dériver la clé symétrique utilisée pour chiffrer les données. Cela pose un problème de sécurité dans l’éventualité où la clé privée du serveur serait compromise. En effet, si un tel cas devait se produire, l'attaquant en possession de la clé privée serait en mesure de déchiffrer toutes les communications passées qu’il aurait pu intercepter et enregistrer, car il est capable de déchiffrer tous les “pre-master password”, et donc de recalculer la clé symétrique utilisée.

La solution

Pour se protéger d’une telle attaque, il est nécessaire d’utiliser un algorithme d’échange de clés vérifiant la propriété de « confidentialité persistante » (souvent appelée « Perfect Forward Secrecy » ou PFS en anglais).

La PFS dans TLS garantit que la compromission des clés à long terme (la clé privée rattachée à la clé publique qui est dans le certificat) d’un serveur (ou d’un client) ne compromet pas la confidentialité des sessions précédentes. Autrement dit, même si un attaquant parvient ultérieurement à obtenir la clé privée du serveur, il ne pourra pas déchiffrer le trafic chifré issu d’échanges TLS passés.

Les algorithmes vérifiant cette propriété sont dits « éphémères », par exemple DHE et ECDHE. Les algorithmes RSA, DH et ECDH ne la vérifient pas et ne sont plus recommandés aujourd’hui.

Fonctionnement des algorithmes éphémères

Chaque connexion utilise une paire de clés asymétriques éphémères, qui va permettre d’échanger entre le client et le serveur, avec l’algorithme de Diffie-Hellman, une clé symétrique (éphémère, elle aussi) qui permettra de chiffrer les données. Ainsi, à l’établissement de la connexion, le serveur crée une nouvelle paire de clés asymétriques qu’il n’utilisera que pour cette session. Le serveur signe ensuite la clé publique avec sa propre clé privée associée au certificat. Cette signature permet au client de vérifier que la clé publique provient bien d’un serveur authentifié et non d’un éventuel imposteur.

L’utilisation de clés éphémères garantit que chaque session dispose de ses propres paramètres secrets. Même si un attaquant parvenait à obtenir la clé privée à long terme du serveur, il ne pourrait pas reconstituer la clé secrète symétrique d’une session, puisque celle-ci dépend de la clé asymétrique éphémère, générée aléatoirement puis détruite une fois l’échange de la clé symétrique terminé. En conséquence, la compromission d’une clé durable n’expose pas l’historique des communications précédentes, assurant ainsi une confidentialité renforcée et continue des échanges.

La version 1.3 de TLS doit être privilégiée : elle garantit la propriété PFS, car elle met en œuvre uniquement les variantes éphémères de l'algorithme de Diffie-Hellman. En revanche, cette version peut ne pas être compatible avec d’anciens appareils. En fonction du contexte, pour disposer d’une compatibilité maximale, on peut utiliser TLS 1.2 en le configurant pour utiliser exclusivement une suite de chiffrement qui repose sur un algorithme d’échange de clés vérifiant la propriété de PFS.

Conclusion

La sécurité des communications en ligne est aujourd'hui un enjeu majeur et le protocole TLS apparaît comme une solution indispensable pour protéger nos échanges sur internet. En combinant cryptographie symétrique et asymétrique, TLS assure la confidentialité, l'intégrité et l'authenticité des données échangées, tout en permettant une négociation dynamique des algorithmes de chiffrement. L'utilisation de certificats numériques, reposant sur une chaîne de confiance établie par des autorités de certification, garantit que les interlocuteurs sont bien ceux qu’ils prétendent être et permet de contrer efficacement les attaques de type MITM.

L'évolution de TLS, notamment sa version 1.3, met l'accent sur la confidentialité persistante grâce à l'usage exclusif d'algorithmes éphémères. Cette approche renforce la sécurité des échanges en s'assurant que même la compromission d'une clé privée à long terme ne met pas en danger les sessions passées. Ainsi, TLS offre un équilibre optimal entre performance et robustesse, en assurant que les échanges sur le web restent protégés.