Comment fonctionne le SSL sans clé ? | Confidentialité persistante

La fonctionnalité SSL sans clé permet aux entreprises qui ne peuvent pas communiquer leurs clés privées de migrer vers le cloud, tout en conservant le chiffrement SSL/TLS.

Objectifs d’apprentissage

Cet article s'articule autour des points suivants :

  • Expliquer les étapes de la négociation TLS et la différence entre une clé de session et une clé privée
  • Comprendre comment la fonctionnalité SSL sans clé établit une séparation entre la partie de la négociation TLS utilisant la clé privée et le reste de la procédure
  • Connaître la différence entre les procédures de négociation Diffie-Hellman et RSA
  • Comprendre ce qu'est la confidentialité persistante

Copier le lien de l'article

Qu'est-ce que le SSL sans clé ?

La fonctionnalité SSL sans clé est destinée aux entreprises qui recourent aux services d'un fournisseur de cloud pour le chiffrement SSL. Ce fournisseur doit généralement connaître la clé privée de l'entreprise, mais le SSL sans clé permet de contourner cette exigence. Pour des motifs juridiques, de nombreuses entreprises ne peuvent pas communiquer leurs clés privées. Grâce à la fonctionnalité SSL sans clé, ces organisations peuvent toujours utiliser le protocole TLS et bénéficier des avantages du cloud, tout en assurant la sécurité de leur clé.

Également connu sous son nom plus exact de TLS, le protocole SSL permet d'authentifier et de chiffrer les communications sur un réseau. Le SSL/TLS nécessite d'avoir recours à ce que nous appelons une clé publique et une clé privée. Ainsi dans le cas d'une entreprise qui utilise ce protocole pour sécuriser le trafic circulant vers et depuis son site web (voir la rubrique HTTP), la clé privée demeure généralement en possession de cette entreprise. Toutefois, lorsqu'une entreprise migre vers le cloud et qu'un prestataire lui fournit un chiffrement TLS, c'est le fournisseur qui détient la clé privée.

En déplaçant la partie de la négociation impliquant la clé privée vers un autre serveur que celui du fournisseur, l'entreprise peut conserver la possession de la clé privée. Plutôt que d'utiliser la clé privée directement pour générer des clés de session, le fournisseur de cloud obtient les clés de session de l'entreprise par l'intermédiaire d'un canal sécurisé et s'en sert pour assurer le chiffrement. La procédure continue donc toujours à impliquer une clé privée, mais cette dernière n'est communiquée à personne en dehors de l'entreprise.

Imaginons, par exemple, que la société Lambda implémente le protocole SSL. Lambda conserve sa clé privée en sécurité sur un serveur qu'elle possède et contrôle. Si Lambda migre vers le cloud et fait appel à un fournisseur de cloud pour l'hébergement web, ce dernier disposera alors de la clé privée. Toutefois, si Lambda choisit un fournisseur qui met en œuvre la fonctionnalité SSL sans clé, la clé privée pourra rester sur le serveur possédé et contrôlé par la société Lambda, comme dans l'implémentation SSL non cloud.

Comment fonctionne le SSL sans clé ?

Le SSL sans clé repose sur le fait que la clé privée n'est utilisée qu'une seule fois au cours de la procédure de négociation TLS, c'est-à-dire au début d'une session de communication TLS. Cette fonctionnalité agit en scindant les étapes de la négociation TLS. Un fournisseur de cloud proposant un service SSL sans clé déplace la partie du processus impliquant la clé privée vers un autre serveur, le plus souvent un serveur situé dans les locaux du client.

Lorsque la clé privée devient nécessaire pour déchiffrer ou chiffrer des données au cours de la procédure de négociation, le serveur du fournisseur transmet les données nécessaires au serveur contenant la clé privée du client. La clé privée chiffre ou déchiffre les données sur le serveur du client et renvoie les données au serveur du fournisseur. La négociation TLS peut alors se poursuivre normalement.

Le SSL sans clé n'est finalement « sans clé » que du point de vue du fournisseur de cloud. Le fournisseur ne voit jamais la clé privée du client, mais ce dernier en conserve néanmoins la possession et l'usage. Parallèlement, l'utilisation de la clé publique continue à s'effectuer de manière tout à fait habituelle côté client.

Qu'est-ce qu'une clé de session ?

Une clé de session constitue une clé symétrique utilisée par les deux interlocuteurs d'une communication sécurisée sur TLS, après la conclusion de la négociation TLS. Une fois que les deux parties se sont mises d'accord sur un ensemble de clés de session, les clés publique et privée ne sont plus nécessaires. TLS génère des clés de session différentes pour chaque session unique.

Quelles sont les étapes de la génération de clés de session ?

Tout dépend de du type d'algorithme d'échange de clés utilisé dans la négociation TLS. Les deux principaux sont l'algorithme d'échange de clés RSA et l'algorithme d'échange de clés éphémères Diffie-Hellman.

L'échange de clés RSA

Dans la procédure RSA, les étapes de la négociation TLS nécessaire pour créer les clés de session sont les suivantes :

  1. Le client envoie (en texte clair) un message « Hello » au serveur. Ce message indique la version de protocole qu'il souhaite utiliser, une liste des suites de chiffrement prises en charge et une courte chaîne de données aléatoires, appelée « client random ».
  2. Le serveur répond (en texte clair) en renvoyant son certificat SSL, son algorithme de chiffrement privilégié et une courte chaîne de données aléatoires, nommée « server random ».
  3. Le client crée un autre ensemble de données aléatoires : le « premaster secret », ou secret pré-maître. Le client chiffre le secret pré-maître à l'aide de la clé publique figurant dans le certificat SSL du serveur et l'envoie à ce dernier. Seul un système disposant de la clé privée peut déchiffrer le secret pré-maître.
  4. Le serveur déchiffre alors le secret pré-maître. Veuillez noter qu'il s'agit de la seule fois que la clé privée est utilisée !
  5. Le client et le serveur disposent désormais du client random, du serveur random et du secret pré-maître. Les deux systèmes combinent ces trois valeurs (indépendamment l'un de l'autre) afin d'obtenir des clés de session. Ils doivent tous deux aboutir au même résultat et toutes les communications ultérieures au cours de la session seront chiffrées à l'aide de ces nouvelles clés.

Le SSL sans clé entre en jeu à l'étape 4. Avec le SSL sans clé, au lieu de déchiffrer le secret pré-maître lui-même, le fournisseur de cloud l'envoie sous forme chiffrée, via un canal sécurisé, à un serveur que le client héberge ou contrôle. La clé privée du client déchiffre le secret pré-maître, qui sera renvoyé au fournisseur de cloud sous forme déchiffrée. Le serveur du fournisseur de cloud l'utilise alors pour obtenir les clés de session et les communications TLS peuvent se poursuivre normalement.

L'échange de clés éphémères Diffie-Hellman

La négociation Diffie-Hellman (DHE) à clés éphémères (« éphémères », car la même clé n'est jamais utilisée deux fois) génère des clés de session à l'aide de l'algorithme Diffie-Hellman, qui permet d'échanger des clés sur un canal non sécurisé. Lors de ce type de négociation TLS, l'authentification par clé privée constitue un processus distinct de la génération de clés de session.

Outre les algorithmes utilisés, la principale différence entre la négociation DHE et la négociation RSA réside dans la manière dont le secret pré-maître est généré. Lors d'une négociation RSA, le secret pré-maître se compose de données aléatoires générées par le client. Lors d'une négociation DHE, le client et le serveur utilisent des paramètres convenus entre eux pour calculer le même secret pré-maître, chacun de leur côté.

  1. Tout comme dans la négociation RSA, le client envoie la version de protocole qu'il souhaite utiliser, une liste des algorithmes de chiffrement pris en charge, et le client random.
  2. Le serveur répond en renvoyant sa suite de chiffrement choisie, un server random et son certificat SSL. C'est la que la négociation DHE commence à différer de la négociation RSA : le serveur envoie également son paramètre Diffie-Hellman (DH), qui servira à calculer le secret pré-maître. Il chiffre également le client random, le server random et le paramètre DH à l'aide de la clé privée du serveur. Il s'agit là de la seule et unique fois où la clé privée est utilisée et cette dernière permet de certifier que le serveur est bien celui qu'il prétend être.
  3. Le client déchiffre le message du serveur à l'aide de la clé publique et authentifie le certificat SSL. Il répond alors en renvoyant son paramètre DH.
  4. Les deux parties calculent le secret pré-maître, chacun de leur côté, à partir du paramètre DH du client et du paramètre DH du serveur.
  5. Elles combinent ensuite ce secret pré-maître avec le client random et le server random afin d'obtenir les clés de session.

La clé privée n'est utilisée qu'à l'étape 2 et c'est là que le SSL sans clé prend tout son sens. À ce stade, le fournisseur SSL/TLS envoie le client random, le server random et le paramètre DH du client au serveur (contrôlé par le client) qui détient la clé privée. Ces informations sont chiffrées à l'aide de la clé privée et renvoyées sous forme chiffrée au fournisseur de cloud, qui les transmet ensuite au client. Le client peut alors déchiffrer ces données à l'aide de la clé publique et la procédure de négociation se poursuit. Le fournisseur de cloud n'a ainsi jamais besoin de manipuler la clé privée.

Si la négociation à clés éphémères Diffie-Hellman nécessite un peu plus de temps que la négociation RSA, elle présente un avantage nommé « confidentialité persistante ». Comme la clé privée n'est utilisée que pour l'authentification, les pirates ne peuvent pas s'en servir pour découvrir les clés de session.

Qu'est-ce que la confidentialité persistante ? Qu'est-ce que la confidentialité persistante parfaite ?

La confidentialité persistante permet de garantir que les données chiffrées restent chiffrées, même en cas d'exposition de la clé privée. On nomme également cette caractéristique « confidentialité persistante parfaite ». La confidentialité persistante est possible lorsqu'une clé de session unique est utilisée pour chaque session de communication et si la clé de session est générée indépendamment de la clé privée. Si la clé d'une session se retrouve compromise, le pirate ne peut déchiffrer que cette dernière. Toutes les autres sessions demeureront chiffrées.

Dans un protocole configuré pour garantir une confidentialité persistante, la clé privée est utilisée à des fins d'authentification au cours de la négociation initiale, mais pas pour le chiffrement. La procédure de négociation à clés éphémères Diffie-Hellman génère des clés de session indépendamment de la clé privée et bénéficie donc de la confidentialité persistante.

À l'inverse, la procédure de négociation RSA ne bénéficie pas de la confidentialité persistante. Lorsque la clé privée est compromise, un pirate peut déchiffrer les clés de session des conversations passées, car il peut déchiffrer le secret pré-maître. Par ailleurs, le client random et le server random sont émis en texte clair. En combinant ces trois valeurs, le pirate peut ainsi dériver la clé de n'importe quelle session.

Comment Cloudflare met en place le SSL sans clé ?

Cloudflare fut le premier fournisseur de cloud à mettre en place une solution de SSL sans clé, qui permet aux entreprises soumises à des contraintes de sécurité strictes, comme les banques, de migrer vers le cloud. Cloudflare prend en charge les négociations RSA et Diffie-Hellman afin de permettre aux entreprises d'intégrer la confidentialité persistante via la procédure Diffie-Hellman et de se protéger contre la possibilité qu'un pirate déchiffre leurs données après avoir volé leur clé privée.

Toutes les communications entre les serveurs de Cloudflare et les serveurs de clés privées transitent via un canal sécurisé et chiffré. En outre, Cloudflare a constaté que le SSL sans clé avait un impact négligeable sur les performances, malgré les trajets supplémentaires vers le serveur contenant les clés privées.

Pour plus de détails techniques concernant le fonctionnement du SSL sans clé, consultez cet article de blog. Pour en savoir plus sur la solution Cloudflare en la matière, consultez les détails de notre service SSL sans clé.