Comment fonctionne le SSL sans clé ?

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 poignée de main impliquant la clé privée hors du serveur du fournisseur, la clé privée peut rester en possession de l'entreprise en toute sécurité. Au lieu d'utiliser la clé privée directement pour authentifier le serveur du fournisseur, le fournisseur de services en nuage transmet des données au serveur de l'entreprise et en reçoit de celui-ci pour ce faire. Cette communication se fait par un canal sécurisé et chiffré. Ainsi, une clé privée est toujours utilisée, mais elle n'est partagée avec personne en dehors de l'entreprise.

Imaginons, par exemple, que la société Lambda implémente le protocole TLS. Lambda conservera 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 de migrer vers le cloud avec un fournisseur qui met en œuvre la fonctionnalité SSL/TLS 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 TSL 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. Le SSL sans clé agit en scindant géographiquement 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.

Comment fonctionne le SSL sans clé avec une poignée de main TLS à échange de clé RSA ?

Dans une poignée de main RSA, les étapes d'une poignée de main TLS 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.

Comment fonctionne le SSL sans clé avec 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 intègre également une signature numérique pour authentification. 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 vérifie la signature numérique du serveur et authentifie le certificat SSL. Le client répond alors avec 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 utilisées pour générer la signature numérique du serveur et renvoyées sous forme chiffrée au fournisseur de cloud, qui les transmet ensuite au client. Le client peut alors vérifier cette signature à 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 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.

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 sans servir d'autres objectifs. 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 RSA ne bénéficie pas de la confidentialité persistante. Si 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 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é.