Qu’est-ce qu’une poignée de main TLS ?

Une négociation de sécurité de la couche de transport (TLS) établit une communication cryptée et authentifiée entre un client (tel qu'un navigateur Web) et un serverLa poignée de main implique l'échange de messages, l'accord sur des informations cryptographiques algorithmes, vérifiant le serverl'identité de (et éventuellement celle du client) et la génération de données partagées clés secrètes pour crypter les suivants transferts de donnéesIl s’agit de la base d’un échange de données sécurisé, garantissant que les informations transmises restent confidentielles et infalsifiables.

Que signifie la poignée de main TLS ?

Une négociation TLS est une série d'étapes qui initient une connexion sécurisée en validant les parties impliquées, en sélectionnant des paramètres de sécurité compatibles et en créant des clés de chiffrement partagées. La négociation détermine la manière dont les données seront chiffrées, vérifie la servercertificat numérique de 's, et établit le canal sécurisé nécessaire pour protéger intégrité des données et la confidentialité. Il s'agit d'un élément essentiel de TLS, un protocole conçu pour assurer la confidentialité et data security sur les réseaux.

Quels sont les composants d’une négociation TLS ?

Vous trouverez ci-dessous les principaux composants qui rendent possible une négociation TLS.

Client et Server

La poignée de main implique deux entités principales : le client, qui initie la connexion (par exemple, un navigateur web ou d'un autre application), et le server, qui héberge la ressource ou le service auquel le client souhaite accéder. Le client démarre la négociation en proposant divers paramètres pour chiffrement et protocoles d'authentificationainsi que, server répond avec ses options choisies en fonction des configurations prises en charge.

Suites de chiffrement

Une suite de chiffrement est un ensemble d'algorithmes cryptographiques utilisés lors de la négociation et des transferts de données ultérieurs. Elle comprend l'algorithme d'échange de clés, le chiffrement de masse, l'algorithme de code d'authentification de message et parfois l'algorithme de signature numérique. Le client suggère une liste de suites de chiffrement qu'il prend en charge et l'algorithme de chiffrement de masse. server en sélectionne un qu’il reconnaît et juge acceptable.

Certificats

Les certificats sont des documents numériques utilisés pour confirmer l'identité d'une partie communicante. Dans la plupart des connexions TLS, le server présente un certificat X.509, qui est émis par un organisme de confiance autorité de certification (CA). Ce certificat lie le server's domaine nom d'une clé publique. Le client vérifie la chaîne de certificats pour s'assurer qu'elle n'a pas été falsifiée et qu'elle a été émise par une autorité de certification légitime.

Clés publiques et privées

Les clés publiques et privées font partie intégrante de TLS. server détient une clé privée qui correspond à la clé publique répertoriée dans son certificat. Lors de la négociation, ces clés participent à des opérations cryptographiques asymétriques. Les clients utilisent la clé publique dans le server certificat pour crypter un élément de données (comme le secret pré-maître), et uniquement le serverLa clé privée de peut décrypter le

Clés de session

Une fois que le client et server s'accordent sur un ensemble de paramètres cryptographiques, ils génèrent des clés de session. Ces clés chiffrent et déchiffrent les messages pendant la phase de transfert de données, offrant ainsi des avantages en termes de confidentialité et de performances. Les algorithmes de chiffrement symétriques sont généralement beaucoup plus rapides que les algorithmes asymétriques, c'est pourquoi la négociation utilise des méthodes asymétriques pour l'authentification et l'échange de clés, puis revient aux méthodes symétriques pour le chiffrement des données en masse.

Comment fonctionne le protocole TLS Handshake ?

La négociation TLS se déroule généralement en plusieurs étapes qui garantissent un canal sécurisé et authentifié. Chaque phase a un objectif défini et consiste en des échanges de messages qui finalisent les paramètres de chiffrement et vérifient l'authenticité du server et éventuellement le client.

ClientBonjour

Le client commence la poignée de main en envoyant un message ClientHello à l' serverCe message contient les informations suivantes :

• Une liste des suites de chiffrement et des versions TLS prises en charge.
• Une valeur aléatoire (client aléatoire) utilisée ultérieurement dans la génération de clé.
• Appareils compression méthodes (bien que la compression soit largement obsolète dans les versions récentes de TLS).

ServerBonjour

Le server répond avec un ServerBonjour message. Cette réponse comprend :

• La version TLS sélectionnée.
• La suite de chiffrement choisie dans la proposition du client.
• Une autre valeur aléatoire (server aléatoire).

Certificat et échange de clés

Le server envoie son certificat, qui contient le serverla clé publique de 's ainsi que la chaîne de certificats. Après cela, le server peut envoyer des paramètres d'échange de clés supplémentaires si la suite de chiffrement choisie l'exige (par exemple, dans Diffie-Hellman ou chiffres Diffie-Hellman à courbe elliptique).

Le client vérifie le serverle certificat de , garantissant qu'il est valide, non expiré et signé par une autorité de certification de confiance.

Vérification du client et secret pré-master

Une fois que le client a vérifié le serverLe certificat de , il génère un secret pré-maître et le crypte à l'aide du serverla clé publique de . Ce secret pré-maître chiffré est ensuite envoyé à server.

Le server utilise sa clé privée pour décrypter le secret pré-maître, et les deux parties dérivent les clés de session du secret pré-maître, du client aléatoire et du server au hasard.

Finalisation de la poignée de main

Le client et server s'envoient mutuellement des messages « Terminé », qui sont chiffrés avec les clés de session nouvellement dérivées. Ces messages vérifient que les clés convenues fonctionnent correctement et qu'aucune altération n'a eu lieu.

Une fois ces messages échangés et vérifiés avec succès, la négociation est terminée et les communications ultérieures sont cryptées à l'aide des clés de session.

Quand une négociation TLS se produit-elle ?

Une négociation TLS se produit chaque fois qu'un client initie une nouvelle connexion sécurisée à un server via TLS. Les scénarios courants incluent :

• Accéder à un site Web via HTTPS (HTTP via TLS).
• Initier email sécurisé communications (telles que SMTP, IMAPS ou POP3S).
• Connexion à des applications sécurisées qui s'appuient sur TLS pour le chiffrement (par exemple, Tunnels VPN ou sécurisé filet transferts).

La poignée de main se répète si une nouvelle session est établie ou si une renégociation TLS est déclenchée pour actualiser les clés cryptographiques pour les connexions de longue durée.

Exemple de négociation TLS

Vous trouverez ci-dessous une procédure pas à pas de la manière dont une négociation HTTPS (HTTP sur TLS) typique se déroule entre un client et un server.

Étape 1 : Le client demande une page sécurisée

Le navigateur Web d'un utilisateur initie une connexion sécurisée en envoyant un message ClientHello à l' server à « exemple.com ». Le message ClientHello fait partie du protocole TLS Handshake et contient plusieurs informations importantes :

• Version(s) de protocole prise(s) en chargeLe client propose une ou plusieurs versions de TLS (par exemple, TLS 1.2, TLS 1.3) qu'il est capable d'utiliser.
• Client aléatoire. Un 32-octet valeur aléatoire générée par le client, utilisée ultérieurement dans la dérivation de la clé.
• ID de session ou ticket de session. Si le client s'est récemment connecté au même server et détient un ticket de session ou un identifiant de session valide, il peut lui proposer de demander la reprise de la session, ce qui peut ignorer ou raccourcir certaines étapes de la négociation.
• Suites de chiffrement. Ces suites sont une liste d'algorithmes cryptographiques pris en charge par le client. Chaque suite de chiffrement spécifie un mécanisme d'échange de clés (par exemple, RSA, ECDHE), un algorithme de cryptage (par exemple, AES) et un code d'authentification de message ou un algorithme de balise d'authentification (par exemple, SHA256).
• ExtensionsLes implémentations TLS modernes incluent diverses extensions telles que server indication du nom (SNI), qui indique le nom d'hôte le client tente d'atteindre. Des extensions supplémentaires peuvent indiquer des courbes elliptiques prises en charge, des algorithmes de signature et d'autres paramètres qui améliorent la sécurité ou les performances.

A la réception de ce ClientHello, le server examine les suites de chiffrement proposées et les versions TLS pour déterminer si elles prennent en charge l'une d'entre elles. La négociation TLS continue uniquement si le server trouve au moins un ensemble de paramètres compatible.

Étape 2: Server Répond

Après avoir traité le ClientHello, le server répond avec un ServerMessage de bienvenue. Plusieurs éléments clés sont inclus :

• Version du protocole choisieL’ server sélectionne une version de TLS (par exemple, TLS 1.2) que le client et server soutien.
• Server aléatoire. Une autre valeur aléatoire de 32 octets générée par le server, utilisé avec le client aléatoire pour dériver des clés partagées.
• Sélection de la suite de chiffrement. À partir de la liste des clients, le server sélectionne une seule suite de chiffrement qu'il prend en charge. Par exemple, il peut choisir un échange de clés ECDHE_RSA, un chiffrement AES_128_GCM et SHA256 pour l'authentification des messages.
• ID de session ou nouveau ticket de session. Si l' server prend en charge la reprise de session, il peut accepter l'ID de session proposé par le client ou en fournir un nouveau.
• ExtensionsL’ server inclut les réponses d'extension pertinentes, indiquant tous les paramètres ou contraintes spécifiques.

Suite au ServerBonjour, un server envoie généralement des messages de poignée de main supplémentaires :

• CertificatL’ server transmet sa chaîne de certificats, qui comprend son certificat d'entité finale (le certificat réel server certificat) et tous les certificats intermédiaires requis pour le lier à une autorité de certification racine (CA).
• Server échange de clés. Selon la suite de chiffrement choisie, le server fournit des paramètres d'échange de clés (par exemple, une clé publique Diffie-Hellman éphémère) que le client utilisera pour générer un secret partagé.
• Demande de certificat (optionnel). Si l' server nécessite une authentification client, il demande un certificat client à ce stade. Cela est moins courant dans la navigation Web classique mais plus fréquent dans les environnements nécessitant un TLS mutuel.

Étape 3 : Validation du certificat

Le client examine le servercertificat de 's pour garantir que la connexion est bien avec l'hôte prévu et non avec un imposteur :

• Vérification de la chaîne de certificats. Le client vérifie que le serverLe certificat de est émis et signé par une autorité de certification de confiance. Le navigateur ou le système d'exploitation maintient un magasin de certificats racines de confiance. Le navigateur vérifie également les certificats intermédiaires pour former une chaîne de confiance valide jusqu'à une autorité de certification racine reconnue.
• Expiration et validitéLe client inspecte les dates « Pas avant » et « Pas après » du certificat pour confirmer que le certificat est actuellement valide.
• Correspondance de noms de domaine. Le client confirme que le nom de domaine répertorié dans le certificat (généralement trouvé dans le champ Nom alternatif du sujet) correspond à « exemple.com » ou au domaine demandé.
• Vérification de révocationLe client peut utiliser la liste de révocation de certificats (CRL) ou le protocole d’état de certificat en ligne (OCSP) pour voir si le certificat ou un certificat intermédiaire a été révoqué.

Si une partie du processus de validation échoue (signature non valide, certificat expiré ou nom de domaine incompatible, par exemple), le client met généralement fin à la connexion ou affiche un avertissement à l'utilisateur.

Étape 4 : Échange de clés et génération de clés de session

Une fois que le client a validé le server(et éventuellement envoyé son propre certificat si demandé), le client procède à l'échange de clés :

• Échange de clés client. Si un échange de clés RSA est utilisé, le client génère un secret pré-maître et le crypte avec le serverla clé publique de (obtenue auprès du server (certificat). Si une suite de chiffrement ECDHE ou DHE est utilisée, le client fournit également sa propre clé publique éphémère pour les calculs Diffie-Hellman.
• Décryptage ou calcul de clé partagéeL’ server décrypte le secret pré-maître avec sa clé privée ou, dans le cas de Diffie-Hellman/ECDHE, combine le secret du client et serverles clés publiques pour calculer un secret partagé.
• Dérivation du secret principal. En utilisant le secret pré-maître (ou le secret partagé DH), le client et server les deux dérivent un secret maître. Cette dérivation implique également le client aléatoire et server aléatoire. Les fonctions pseudo-aléatoires (comme celles de TLS 1.2 ou le « Handshake Secret » de TLS 1.3) sont utilisées pour garantir un caractère aléatoire cryptographique fort.
• Création de clé de session. À partir du secret principal, le client et server générer des clés symétriques distinctes pour chiffrer les données sortantes, déchiffrer les données entrantes et vérifier l'intégrité des messages. Ces clés de session sont généralement négociées pour être éphémères (en particulier dans les chiffrements basés sur ECDHE), ce qui fournit transmettre le secret.

Étape 5 : Transfert sécurisé des données

Une fois que les deux parties ont obtenu les clés de session, le client et server échange Fini messages:

• Messages terminés. Chaque partie calcule un hachage cryptographique de tous les messages de négociation envoyés jusqu'à présent (la transcription de la négociation) et le crypte avec les clés de session nouvellement établies. Ces messages « Terminé » vérifient que les deux parties partagent le même état de négociation et qu'aucune altération n'a eu lieu.
• Confirmation de la poignée de main. Le client et server confirmer la réception du message terminé de l'autre. Si les hachages correspondent, cela indique que la négociation s'est déroulée avec succès et en toute sécurité.
• Données d'application cryptées. Données ultérieures, telles que HTML fichiers, images ou tout autre contenu de la couche applicative, sont chiffrés avec la clé symétrique convenue. Le chiffrement garantit la confidentialité, tandis que la clé cryptographique hachage ou MAC (selon la suite de chiffrement) garantit l'intégrité.
• Persistance de la connexion et reprise de session. Si l'une des deux parties prend en charge la reprise de session TLS, elle peut réutiliser le secret maître négocié pour une future connexion. Cela réduit la charge de travail nécessaire pour effectuer à nouveau une négociation complète.

Une fois la phase de négociation terminée, le navigateur et server communiquer via un canal sécurisé. Les navigateurs affichent généralement une icône de verrouillage ou un indicateur similaire dans la barre d'adresse pour indiquer que la connexion est cryptée et authentifiée à l'aide de TLS.

Pourquoi les poignées de main TLS sont-elles importantes ?

Une négociation TLS fournit une méthode permettant d'établir des communications sécurisées dans des réseaux susceptibles d'être écoutés ou falsifiés.

 Une poignée de main réussie présente plusieurs avantages :

• Authentification. Le client est assuré de la serverl'identité de , empêchant attaques de l'homme du milieu.
• ConfidentialitéTout le trafic qui suit la poignée de main est crypté, ce qui garantit que les parties non autorisées ne peuvent pas lire les données.
• Intégrité des donnéesL'authentification des messages garantit que les données transmises n'ont pas été modifiées pendant le transit.

Le processus de négociation, grâce à l’utilisation d’algorithmes et de certificats cryptographiques, établit une couche de confiance robuste qui protège les informations pendant le transit.

Que se passe-t-il si une négociation TLS échoue ?

L'échec d'une connexion TLS entraîne l'impossibilité de créer une connexion sécurisée. La connexion est souvent interrompue et les utilisateurs peuvent rencontrer des messages d'erreur tels que «SSL / TLS « Échec de la négociation » ou « Impossible d'établir une connexion sécurisée ».

L'échec se produit lorsque des problèmes tels que des versions TLS incompatibles, des certificats non valides, des certificats expirés ou des horloges système incorrectes empêchent une négociation réussie.

Comment réparer une poignée de main TLS ?

Administrateurs système et les utilisateurs finaux peuvent résoudre les échecs de négociation en s'attaquant aux causes profondes :

• Mettre à jour ou installer des certificats valides. Vous devez remplacer les certificats expirés ou non valides. Les fournisseurs d'hébergement et les administrateurs doivent s'assurer que les certificats sont signés par des autorités de certification approuvées et restent à jour.
• Vérifiez la configuration et les protocoles pris en charge. S'assurer que le client et server Il est essentiel de prendre en charge les mêmes versions TLS et suites de chiffrement. La désactivation des anciens protocoles tels que SSLv3 ou TLS 1.0 élimine les vulnérabilités connues vulnérabilités et évite les échecs de négociation liés aux méthodes de chiffrement obsolètes.
• Synchroniser les horloges systèmeDes horloges système précises sont importantes pour valider les heures d'expiration et de validité des certificats. server ou un client avec un réglage d'heure incorrect peut rejeter des certificats pourtant valides.
• Vérifier les magasins de confiance CA. Le système d'exploitation ou l'application du client conserve une liste d'autorités de certification approuvées. La vérification de la présence et de la révocation de l'autorité de certification racine ou intermédiaire concernée permet d'éviter les erreurs de négociation.
• Inspecter server paramétrage. Mal configuré servers (par exemple, des priorités de suites de chiffrement incorrectes ou des chaînes de certificats incomplètes) conduisent souvent à des problèmes de négociation. server les journaux et les configurations aident à identifier l'incompatibilité et permettent une résolution rapide.

Quelle est la différence entre SSL et TLS Handshake ?

Le terme « poignée de main SSL » fait référence au processus de poignée de main utilisé par le couche de sockets sécurisée (SSL) Protocole qui était une norme antérieure pour le cryptage et la sécurisation des données. Le protocole TLS est l'évolution moderne du SSL, offrant des mesures de sécurité plus solides et des algorithmes cryptographiques mis à jour.

Bien que les flux de travail soient similaires, TLS a apporté des améliorations par rapport à SSL, notamment des suites de chiffrement améliorées, une meilleure gestion des certificats et des mécanismes cryptographiques plus robustes. SSL est obsolète en raison de vulnérabilités connues, et la plupart des systèmes modernes utilisent TLS pour les communications sécurisées.

De nombreuses références utilisent encore le terme « SSL » pour décrire le protocole de transfert sécurisé, même lorsque TLS est utilisé en arrière-plan, mais le terme le plus précis dans les implémentations actuelles est « protocole de transfert TLS ». Le principe de base reste le même : un processus de transfert négocie les paramètres de sécurité, échange des certificats et établit des clés partagées pour une communication chiffrée.