Comment fonctionne le SSL sans clé ? | La confidentialité persistante

Keyless SSL permet aux entreprises qui ne peuvent pas partager leurs clés privées de migrer vers le cloud tout en conservant le cryptage 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 de la handshake TLS utilisant la clé privée et le reste de la handshake
  • Connaître la différence entre les procédures de handshake Diffie-Hellman et RSA
  • Comprendre la confidentialité persistante

Qu'est-ce que Keyless SSL ?

Keyless SSL

Keyless SSL est destiné aux entreprises qui recourent aux services d'un fournisseur de cloud pour le cryptage SSL. Cela signifie généralement que le fournisseur de cloud doit connaître la clé privée de l'entreprise, mais la solution Keyless SSL 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, celles-ci peuvent toujours utiliser le TLS et bénéficier du cloud tout en gardant leur clé secrète.

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 à destination et en provenance de son 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 prestataire propose un cryptage TLS, c'est ce dernier qui détient la clé privée.

En déplaçant la partie de la handshake contenant la clé privée qui se trouve sur le serveur du fournisseur, cette dernière peut rester en toute 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 prestataire de services de 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 hors de l'entreprise.

Par exemple, supposons que la société Acme se dote du protocole SSL. Acme conserve sa clé privée en toute sécurité sur un serveur qu'elle possède et contrôle. Si Acme migre vers le cloud et fait pour cela appel à un fournisseur de cloud pour héberger son site, ce dernier disposera alors de la clé privée. Cependant, si Acme choisit un fournisseur qui utilise le SSL sans clé, la clé privée peut rester sur le serveur possédé et contrôlé par Acme.

Comment fonctionne le SSL sans clé ?

Keyless SSL s'appuie sur un principe selon lequel la clé privée n'est utilisée qu'une seule fois au moment de la procédure de handshake TLS, qui a lieu au début d'une session de communication TLS. Keyless SSL agit en scindant les étapes de la procédure de handshake TLS. Un fournisseur de cloud proposant le SSL sans clé déplace la portion du processus correspondant à la clé privée sur un autre serveur, le plus souvent un serveur situé dans les locaux du client.

Lorsque la clé privée devient nécessaire lors de 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.

Keyless SSL n'est « sans clé » que du point de vue du fournisseur de cloud : ce dernier ne voit jamais la clé privée de son client, mais il la possède et l'utilise quand même. Parallèlement, la clé publique est toujours utilisée du côté du client comme à l'accoutumée.

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, une fois la handshake TLS exécutée. 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 publiques et privées. TLS génère des clés de session différentes pour chaque session unique.

Quelles sont les étapes de la génération des 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ère Diffie-Hellman.

L'échange de clés RSA

Les étapes de la création de clés de session dans le cadre d'une procédure de handshake RSA 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 algorithmes 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 ». 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. 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 chacun de leur côté ces trois éléments pour obtenir des clés de session. Ils doivent tous deux obtenir le 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

C'est lors de l'étape 4 que Keyless SSL entre en jeu. 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, puis ce dernier est renvoyé au fournisseur de cloud. Ce dernier s'en sert 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ère Diffie-Hellman

La procédure de handshake Échange de clés Diffie-Hellman (DHE) (« éphémère » 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é. 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 la procédure de handshake DHE et la procédure RSA, outre les algorithmes utilisés, est la manière dont le secret pré-maître est généré. Dans le cadre d'une procédure de handshake RSA, le secret pré-maître est constitué de données aléatoires générées par le client ; dans le cadre d'une procédure de handshake DHE, le client et le serveur utilisent des paramètres convenus entre eux pour calculer séparément le même secret pré-maître.

  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 en indiquant l'algotithme de chiffrement qu'il a choisi, un server random et son certificat SSL. C'est là que la procédure de handshake DHE commence à se distinguer de la procédure de handshake RSA : Le serveur envoie également son paramètre Diffie-Hellman (DH), qui sera utilisé pour calculer le secret pré-maître. Elle 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 que la clé privée est utilisée, et elle permet de confirmer 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 interlocuteurs 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 de SSL sans clé prend tout son sens. À ce stade, le prestataire de services de cloud utilisant le SSL/TLS envoie le paramètre DH du client random, du server random et du serveur au serveur contrôlé par le client où se trouve 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. Ce dernier 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 éphémères Diffie-Hellman nécessitent un peu plus de temps que les handshakes RSA, elles 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 une quelconque clé de session.

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

La confidentialité persistante garantit que les données chiffrées restent chiffrées même si la clé privée est découverte. C'est ce que l'on appelle la « confidentialité persistante parfaite ». La confidentialité persistante est rendue possible lorsqu'une clé de session unique est utilisée pour chaque session de communication et que la clé de session est générée indépendamment de la clé privée. Si une seule clé de 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 éphémère 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.

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 et les client randoms et server randoms sont en texte clair. En combinant ces trois éléments, il peut obtenir n'importe quelle clé de session.

Comment Cloudflare met-elle 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 procédures de handshake RSA et Diffie-Hellman afin que les entreprises puissent bénéficier de la confidentialité persistante de la procédure Diffie-Hellman et se protéger contre le risque 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é et chiffré. En outre, Cloudflare a constaté que le SSL sans clé a un impact négligeable sur les performances, malgré les connexions supplémentaires au serveur contenant les clés privées.

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