Comment fonctionne Keyless SSL ? | Confidentialité persistante

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

Share facebook icon linkedin icon twitter icon email icon

SSL sans clé

Objectifs d’apprentissage

Après avoir lu cet article, vous pourrez :

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

Qu'est-ce que Keyless SSL ?

Keyless SSL

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

Le SSL, ou plutôt TLS, est un protocole d'authentification et de chiffrement des communications sur un réseau. Le SSL/TLS nécessite d'avoir recours à ce que l'on appelle une clé publique et une clé privée, et dans le cas d'une entreprise utilisant le protocole pour sécuriser le trafic vers et depuis site web (voir HTTPS), la clé privée reste généralement en possession de l'entreprise, mais lorsqu'une entreprise migre vers le cloud et qu'un fournisseur cloud propose un chiffrement TLS, c'est le fournisseur qui détient la clé privée.

En déplaçant la partie du handshake impliquant la clé privée à l'extérieur du serveur du fournisseur, la clé privée peut rester en sécurité en possession de l'entreprise. Au lieu d'utiliser la clé privée directement pour générer des clés de session, le fournisseur cloud obtient les clés de session de l'entreprise via un canal sécurisé et les utilise pour assurer le chiffrement. Ainsi, une clé privée est toujours utilisée, mais elle n'est communiquée à personne en dehors de l'entreprise.

Par exemple, supposons que la société Acme implémente le protocole SSL. Acme conserve sa clé privée en sécurité sur un serveur qu'elle possède et contrôle. Si Acme migre vers le cloud et fait appel à un fournisseur de cloud pour l'hébergement web, le fournisseur disposera alors de la clé privée. Cependant, si Acme choisit un fournisseur qui implémente le SSL sans clé, la clé privée peut rester sur le serveur qu'Acme possède et contrôle 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 pendant la procédure de handshake TLS, au début d'une session de communication TLS. Le SSL sans clé agit en scindant les étapes de la procédure de handshake TLS. Un fournisseur de cloud proposant le SSL sans clé déplace la partie clé privée du processus vers un autre serveur, le plus souvent un serveur situé dans les locaux du client.

Lorsque la clé privée devient nécessaire au cours de la procédure de handshake pour déchiffrer ou chiffrer des données, 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, et la procédure de handshake TLS se poursuit normalement.

Le SSL sans SSL n'est en fait « sans clé » que du point de vue du fournisseur de cloud : ce dernier ne voit jamais la clé privée de son client, mais le client l'a et l'utilise quand même. Parallèlement, la clé publique est toujours utilisée du côté du client de façon tout à fait normale.

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

Une clé de session est une clé symétrique utilisée par les deux interlocuteurs d'une communication sécurisée sur TLS, après que le handshake TLS est effectué. Une fois que les deux parties se sont mises d'accord sur un ensemble de clés de session, il n'est plus nécessaire d'utiliser les clés publique et privée. 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 ?

Cela dépend du type d'algorithme d'échange de clés utilisé dans la procédure de handshake 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 un handshake RSA, les étapes d'un handshake TLS pour créer les clés de session sont les suivantes :

  1. Le client envoie au serveur un message « Hello » en texte clair qui indique la version de protocole qu'il souhaite utiliser, une liste des suites de chiffrement pris en charge et une courte chaîne de données aléatoires appelée « client random ».
  2. Le serveur répond (en texte clair) avec son certificat SSL, son algorithme de chiffrement privilégié et une courte chaîne de données aléatoires, appelée « server random ».
  3. Le client crée un autre ensemble de données aléatoires, appelé « secret pré-maître » (premaster secret). En se servant de la clé publique du certificat SSL du serveur, le client chiffre le secret pré-maître et l'envoie au serveur. Seule une personne possédant la clé privée peut déchiffrer le secret pré-maître.
  4. Le serveur déchiffre le secret pré-maître (premaster secret). Notez que c'est 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. Ils combinent ces trois valeurs indépendamment l'un de l'autre pour obtenir des clés de session. Ils doivent tous deux arriver au même résultat, et toutes les communications ultérieures pendant la session seront chiffrées avec ces nouvelles clés.
SSL Handshake (RSA) Without Keyless SSL

Le SSL sans clé entre en jeu à l'étape 4. Avec le SSL sans clé, le fournisseur de cloud, au lieu de déchiffrer le secret pré-maître lui-même, 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, puis le secret pré-prémaître déchiffré est renvoyé au fournisseur de cloud. Le serveur du fournisseur de cloud l'utilise pour obtenir les clés de session, et les communications TLS se poursuivent normalement.

Cloudflare Keyless SSL Handshake (RSA)

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

Un handshake Diffie-Hellman (DHE) à clés éphémères (« éphémère » parce que 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é. Avec ce type de handshake TLS, l'authentification par clé privée est un processus distinct de la génération de clés de session.

La principale différence entre le handshake DHE et le handshake RSA, outre les algorithmes utilisés, est la manière dont le secret pré-maître est généré. Dans un handshake RSA, le secret pré-maître est constitué de données aléatoires générées par le client. Dans un handshake DHE, le client et le serveur utilisent des paramètres convenus entre eux pour calculer le même secret pré-maître séparément.

  1. Tout comme dans une procédure de handshake 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 avec sa suite de chiffrement choisie, un server random et son certificat SLL. C'est ici que le handshake DHE commence à se différentier du handshake RSA : le serveur envoie également son paramètre Diffie-Hellman (DH), qui sera utilisé pour calculer le secret pré-maître. Il chiffre également le client random, le server random et le paramètre DH avec la clé privée du serveur. C'est la seule fois où la clé privée est utilisée, et elle certifie que le serveur est bien celui qu'il prétend être.
  3. Le client déchiffre le message du serveur avec la clé publique et authentifie le certificat SSL. Le client répond ensuite en indiquant son paramètre DH.
  4. Grâce au paramètre DH du client et au paramètre DH du serveur, les deux parties calculent chacun de leur côté le secret pré-maître.
  5. Ils combinent ensuite ce secret pré-maître avec le client random et le server random pour obtenir les clés de session.
SSL Handshake (Diffie-Hellman) Without Keyless SSL

La clé privée n'est utilisée qu'à l'étape 2, et c'est là que la solution Keyless SSL 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 avec la clé privée et sont renvoyées sous forme chiffrée au fournisseur de cloud qui les transmet au client. Le client peut déchiffrer ces données avec la clé publique, et la procédure de handshake se poursuit. De cette façon, le fournisseur de cloud n'a pas besoin de toucher à la clé privée.

Cloudflare Keyless SSL (Diffie Hellman)

Bien que les handshakes à clés éphémères Diffie-Hellman nécessitent un peu plus de temps que les handshakes RSA, ils présentent un avantage appelé « confidentialité persistante ». Étant donné que la clé privée n'est utilisée que pour l'authentification, les pirates ne peuvent pas l'utiliser pour découvrir les clé de session.

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

La confidentialité persistante garantit que les données chiffrées restent chiffrées même si la clé privée est exposée. Cette caractéristique s'appelle la « 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 est compromise, seule cette session peut être déchiffrée par un pirate, toutes les autres sessions resteront chiffrées.

Dans un protocole configuré pour garantir une confidentialité persistante, la clé privée est utilisée pour l'authentification au cours d'une procédure de handshake initiale, et n'est pas utilisée pour le chiffrement. La procédure de handshake à clés éphémères de 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.

Par contre, la procédure de handshake 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 en texte clair. En combinant les trois, le pirate peut en dériver toute clé de 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 handshake RSA et Diffie-Hellman afin que les entreprises puissent intégrer la confidentialité persistante via le handshake Diffie-Hellman et 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 contenant les clés privées transitent via un canal sécurisé chiffré. En outre, Cloudflare a constaté que le SSL sans clé a un impact négligeable sur les performances, malgré les trajets supplémentaires vers le serveur contenant les clés privées.

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