Le cadenas vert démystifié : comment fonctionne le handshake SSL ?

Chaque jour, lorsque vous naviguez sur le Web en toute sécurité, vous pensez au fameux cadenas vert près de l'adresse URL du site Web dans votre navigateur et à la version HTTPS du protocole de transfert de données. Dans cet article, nous allons découvrir pourquoi HTTPS est vraiment sécurisé et comment la communication est protégée contre les écoutes clandestines par un tiers.

Tout d'abord, nous présenterons brièvement les deux concepts cryptographiques de base : la signature numérique et le chiffrement, nous plongerons dans un processus appelé SSL handshake , qui est effectué avant que le client et le serveur ne commencent à échanger des communications et est utilisé pour établir un contexte cryptographique sécurisé. Nous terminerons avec des informations sur la façon d'augmenter encore plus la sécurité avec une étape facultative appelée authentification du certificat client.

Cryptographie à clé publique 101 : paire de clés

Rencontrez Alice et Bob, deux personnes qui ont décidé d'utiliser des méthodes cryptographiques pour échanger leurs messages privés en toute sécurité. Le premier choix auquel ils doivent faire face est entre deux types de cryptographie différents : la cryptographie à clé symétrique et asymétrique (également appelée crypto à clé publique).

Mais attendez, quelles sont ces clés ? Fondamentalement, nous pouvons simplifier qu'une clé est une séquence aléatoire de caractères. Nous pouvons utiliser cette séquence pour transformer (faire une certaine opération cryptographique) sur un message - nous allons creuser cela bientôt.

Cryptographie à clé symétrique

Lors de l'utilisation de la cryptographie à clé symétrique, un expéditeur génère une clé, puis la duplique pour le destinataire. L'expéditeur enregistre la clé originale et un duplicata est remis au destinataire. La même clé est utilisée pour les opérations de chiffrement aux deux extrémités de la communication.

Et quels sont les principaux avantages et inconvénients de la cryptographie à clé symétrique ?

Cryptographie à clé asymétrique

Lors de l'utilisation de la cryptographie à clé asymétrique, l'expéditeur et le destinataire génèrent une paire de clés - une clé publique et une clé privée. Les clés sont mathématiquement couplées les unes aux autres pour fonctionner ensemble dans diverses opérations de chiffrement. L'expéditeur et le destinataire enregistrent leurs clés privées en toute sécurité, mais ils peuvent échanger des clés publiques sans précautions particulières. Ils peuvent même utiliser une sorte de "pages jaunes de clés publiques" - un serveur de clés publiques pour envoyer leurs clés publiques afin qu'elles soient accessibles à tous.

Quels sont les avantages et les inconvénients de la cryptographie à clé asymétrique ?

Puisqu'une configuration cryptographique asymétrique est plus sécurisée, Alice et Bob ont décidé d'y aller ! Maintenant, ils peuvent en tirer parti et commencer à penser à assurer la sécurité et l'intégrité de la communication.

Cryptographie à clé publique 101 : Chiffrement

Lorsqu'Alice envoie un message à Bob, elle veut s'assurer que personne d'autre ne peut en voir le contenu. Elle décide de chiffrer le message. Pour y parvenir, Alice doit d'abord obtenir la clé publique de Bob soit à partir d'un serveur de clés, soit directement auprès de Bob via un canal de communication. Une fois qu'Alice a obtenu la clé, elle peut appliquer une opération de cryptage à l'aide de la clé publique de Bob sur le message qu'elle souhaite envoyer.

D'une manière générale, dans ce processus, le message est pris par un algorithme cryptographique (alias chiffrement) en blocs (le plus souvent) et certaines opérations sur les bits entre le message et la clé sont effectuées, produisant une sortie qui est le message chiffré (alias texte chiffré) . Lorsque Bob reçoit le message crypté, il est la seule personne qui peut le décrypter avec sa clé privée.

Noter:

• Cryptage des messages - l'expéditeur crypte un message avec la clé publique du destinataire
• Décryptage des messages - le destinataire décrypte un message avec sa clé privée

Cryptographie à clé publique 101 : Signature

En plus d'empêcher la révélation du contenu du message, il est tout aussi important de pouvoir confirmer l'identité de l'expéditeur et de vérifier si le message n'a pas été modifié. Une signature numérique (un objet distinct attaché au message) est utilisée exactement pour ces deux raisons.

Alice utilise d'abord un algorithme de hachage pour développer un hachage de message afin de générer sa signature. Le hachage consiste à calculer une fonction mathématique à sens unique sur un message qui produit une sortie à valeur fixe plus courte - différente pour une entrée différente. Ensuite, elle utilise sa clé privée pour chiffrer (signer) le hachage généré.

Ensuite, lorsque Bob reçoit le message et la signature, il peut d'abord déchiffrer la signature à l'aide de la clé publique d'Alice. Lorsque cela réussit, il sait que la signature a bien été générée par Alice (sinon, le déchiffrement avec sa clé publique échouerait).

Deuxièmement, Bob peut prendre le message et le hacher en utilisant le même algorithme qu'Alice avait auparavant et confirmer que son hachage du message est le même que celui généré par Alice. Lorsque les hachages correspondent, il sait que le message n'a pas été falsifié.

Noter:

• Génération de signature - l'expéditeur crypte (signe) le hachage du message avec sa clé privée et crée une signature
• Vérification de la signature - le destinataire déchiffre d'abord le hachage du message à partir de la signature et vérifie si un hachage calculé par lui correspond à celui de la signature
• Le cryptage et la signature peuvent être utilisés séparément , mais pour une sécurité maximale, ils sont généralement combinés. Par conséquent, la plupart des fonctions de chiffrement que vous pouvez rencontrer sont appelées encryptSignMessage() , decryptVerifyMessage() , etc.

J'espère que vous n'avez pas de mal à suivre l'histoire d'Alice & Bob. Permettez-moi d'illustrer à nouveau l'ensemble du flux pour m'assurer que tout est clair et résumer les choses.

1. Alice veut envoyer un message à Bob
2. Alice prend sa clé privée et génère une signature
3. Alice prend la clé publique de Bob et crypte le message
4. Alice envoie le message à Bob
5. Bob prend la clé publique d'Alice et vérifie la signature
6. Bob utilise sa clé privée pour déchiffrer le message

Bon, assez de théorie. Voyons maintenant comment tout cela est utilisé en HTTPS !

Prise de contact SSL

Dites bonjour s'il vous plaît

Lorsqu'un client initie une connexion à un serveur, il est d'abord essentiel de faire une introduction appropriée pour établir le contexte cryptographique pour le reste de la communication. Cela peut être fait à l'étape HTTPS CONNECT, bien avant l'analyse des en-têtes et des corps de requête. Tout commence par l' envoi par le client d'un message bonjour au client .

Plus important encore, le message contient les algorithmes de cryptage que le client comprend et du matériel supplémentaire, comme les algorithmes de compression pris en charge, les versions de protocole, l'identifiant de session, etc. Comme le serveur aime être poli, il répond également avec un message de bonjour du serveur qui notamment contient le certificat du serveur avec la clé publique du serveur (oui, le processus est basé sur la cryptographie à clé publique - la même méthode qu'Alice et Bob ont choisie).

Autorité de certification

Il est maintenant temps d'accueillir notre prochain invité à l'étape : une autorité de certification (CA). Le nom semble sérieux - mais ce n'est qu'une entité tierce avec beaucoup de crédit de rue qui est fondamentalement considérée comme digne de confiance dans le monde entier. Une telle entité peut valider l'identité d'un serveur et placer sa signature numérique avec le certificat du serveur (comme Alice lors de la messagerie avec Bob).

Vérification du certificat

Considérons enfin le titre cadenas vert à côté de l'adresse URL de votre navigateur.

Chaque client Web dispose d'une liste groupée de clés publiques d'autorités de certification bien connues et approuvées. Vous vous souvenez peut-être qu'au début de l'article, j'ai mentionné que la signature est générée à l'aide de la clé privée de l'expéditeur et peut être vérifiée à l'aide de la clé publique de l'expéditeur. Eh bien, c'est exactement ce que fait le client . Il parcourt la liste groupée des autorités de certification de confiance et vérifie si la signature du certificat de serveur appartient à l'une des autorités de certification de confiance. Si c'est le cas, il accepte le certificat – et c'est à ce moment-là que le cadenas devient vert .

Mais ce n'est qu'un premier pas, qui n'a encore rien à voir avec la sécurité. N'importe qui peut copier n'importe quel certificat de clé publique, le mettre sur un serveur et le présenter à un client qui se connecte, n'est-ce pas ?

Une fois que le client a vérifié le certificat du serveur, il crée une clé symétrique pour chiffrer la communication. Mais, comme je l'ai mentionné au début, le problème avec les clés symétriques est qu'elles sont susceptibles d'être interceptées pendant le transport. A cette étape, le client et le serveur n'ont pas de contexte cryptographique commun. Ainsi, le client envoie la clé symétrique au serveur, mais il la chiffre d'abord avec la clé publique du serveur. Ensuite, le serveur le reçoit et doit pouvoir le déchiffrer pour établir une connexion sécurisée.

Par conséquent, même si quelqu'un présentait un certificat de clé publique volé , c'est l'étape qu'il échouerait. Une clé privée valide liée à la clé publique du certificat du serveur est essentielle pour déchiffrer la clé symétrique. Bien sûr, ce n'est pas un problème pour un serveur légitime car il a la clé privée enregistrée en toute sécurité. Il peut être utilisé pour déchiffrer la clé symétrique et chiffrer les communications ultérieures.

Donc, pour résumer, une poignée de main SSL est un processus dans lequel les types de cryptographie symétrique et asymétrique sont utilisés . Au début, la paire de clés asymétriques initie la connexion et fournit un moyen sûr pour que la clé symétrique se déplace. Comme nous l'avons souligné au début, les opérations de cryptographie symétrique sont plus rapides, il est donc avantageux de l'utiliser pour l'ensemble de la communication après la configuration. De plus, une fois qu'une connexion sécurisée est établie, elle est réutilisée jusqu'à son expiration, de sorte que la configuration de la clé asymétrique n'est pas effectuée avant chaque demande du client.

Il convient également de mentionner que dans la vraie vie, les certificats ne sont pas signés directement par les autorités de certification de confiance les plus connues (appelées racines ). Pourtant, les autorités de certification racine signent des certificats intermédiaires, qui signent ensuite le certificat du serveur, créant ainsi une chaîne de certificats, que le client qui se connecte vérifie jusqu'à ce qu'une signature valide soit trouvée. Cela offre certainement une meilleure sécurité - lorsque l'une des autorités de certification intermédiaires est compromise, cela affecte moins de personnes.

Validation du certificat client

Maintenant, il y a une étape facultative que nous pouvons mentionner brièvement, car nous avons toutes les connaissances nécessaires pour la comprendre. Un serveur peut être configuré pour demander et valider un certificat client après avoir établi une connexion sécurisée afin d'obtenir une sécurité supplémentaire.

Cela fonctionne de la même manière - mais cette fois, le client envoie son certificat et le serveur parcourt sa liste d'autorités de certification de confiance et la vérifie. Il convient également de noter que le serveur est sous le contrôle des développeurs (contrairement à un client, c'est-à-dire un navigateur Web ou un système d'exploitation mobile), de sorte que les développeurs backend peuvent facilement modifier la liste des certificats de confiance.

Les réseaux d'entreprise utilisent couramment ce mécanisme. Le plus souvent, les certificats clients sont générés par un système de gestion d'appareil installé sur l'appareil de l'employé et sont signés avec un certificat racine généré par l'entreprise. Le même certificat est également ajouté à l'environnement backend. De cette façon, le backend de l'entreprise peut facilement vérifier le certificat lorsque le client se connecte.

Parcourons nos solutions backend

Lire la suite

Maintenant, pour résumer, voyons un diagramme pour l'ensemble du flux :

Sommaire

Vous êtes arrivé à la fin de l'article ! J'espère que vous comprenez déjà le mécanisme de mise en œuvre de la configuration du chiffrement dans HTTPS et les méthodes d'application des processus de signature et de chiffrement.

Puisque vous savez comment les choses fonctionnent, vous devriez certainement vous sentir plus confiant quant au cryptage des données. Néanmoins, il est essentiel de se rappeler qu'un cadenas vert dans votre navigateur ne garantit pas encore la sécurité . Dans le contexte sensible à la sécurité, vous devez également examiner attentivement le certificat. Comme on dit, prévenu est prévenu !