Comment TLS établit une connexion web sécurisée et ce que vérifie le navigateur

Lorsque vous ouvrez une page HTTPS, le navigateur et le serveur doivent convenir de la manière de protéger la communication avant d'échanger les données de l'application. Cette négociation initiale est connue sous le nom de poignée de main TLS. Ce n'est pas un mot de passe saisi par l'utilisateur : c'est un échange automatique de messages et de paramètres cryptographiques.

TLS protège les données en transit par la confidentialité et l'intégrité, et permet d'authentifier le serveur. Le résultat pratique est un canal dans lequel un observateur du réseau ne devrait pas pouvoir lire ni modifier silencieusement le trafic. TLS ne chiffre pas par lui-même les informations stockées sur les appareils ou les serveurs, ni ne décide si le contenu du site est honnête.

SSL est le nom du protocole prédécesseur, désormais obsolète ; dans les connexions web actuelles, le protocole pertinent est TLS. Par habitude, on parle encore de « certificats SSL », mais le certificat est une crédence numérique et TLS est le protocole qui établit et protège la connexion. Certificat et protocole sont des pièces distinctes : en avoir un installé ne suffit pas à démontrer que la configuration TLS est bien faite.

Au début, le client envoie un message ClientHello avec des informations sur les options qu'il prend en charge, comme les versions de TLS, les algorithmes et les données pour l'échange de clés. Le serveur répond en sélectionnant des paramètres compatibles. Aucune combinaison arbitraire n'est choisie : les deux extrémités doivent s'accorder sur les options autorisées par leurs implémentations et configurations.

Dans TLS 1.3, le client peut inclure dès le premier message une partie publique de l'échange de clés éphémère. Le serveur sélectionne les paramètres, présente son certificat et envoie sa partie correspondante ; les deux extrémités dérivent indépendamment des secrets partagés et des clés de trafic. Avec ECDHE —Diffie-Hellman éphémère sur courbes elliptiques— la clé secrète de session n'est pas transmise comme une donnée qu'un tiers pourrait copier : des valeurs publiques sont échangées permettant de calculer le secret des deux côtés.

Le chiffrement symétrique protège le trafic ultérieur car il est plus adapté au traitement de grandes quantités de données que les opérations à clé publique. TLS dérive des clés de trafic pour protéger les enregistrements de la connexion ; il ne convient pas de décrire le processus comme si le navigateur créait simplement une clé de session et la remettait au serveur. Le design exact dépend de la version négociée et des paramètres convenus.

TLS 1.3 a réduit l'établissement ordinaire à un aller-retour de réseau (1-RTT), tandis que TLS 1.2 en nécessite généralement deux avant de commencer l'échange normal de données protégées. La reprise de session avec 0-RTT est une option distincte : elle peut permettre d'envoyer des données avant de compléter un nouvel aller-retour, mais elle comporte des risques de rejouage et n'est pas indistinctement appropriée pour les opérations qui ne tolèrent pas les doublons. Une latence plus faible ne signifie pas que toutes les requêtes sont sûres pour 0-RTT.

Le certificat du serveur lie une identité —généralement un nom de domaine— à une clé publique et contient une signature vérifiable au sein d'une chaîne de confiance. Le client vérifie que la chaîne mène à une autorité racine qu'il reconnaît, que le certificat est dans sa période de validité et que le nom demandé correspond aux noms couverts par le certificat, habituellement dans le champ SAN (Subject Alternative Name).

La validation ne consiste pas seulement à regarder s'il y a un cadenas. Le navigateur effectue des vérifications automatiques et peut rejeter la connexion si le certificat est expiré, si le nom ne correspond pas ou si la chaîne ne peut pas être validée. La vérification de révocation dépend également des mécanismes et politiques du client ; on ne doit pas supposer qu'une inspection visuelle de l'icône expose tous les détails de ce processus.

Un certificat valide authentifie le contrôle d'un domaine selon les règles d'émission applicables ; il ne certifie pas que l'entreprise est légitime, que le site n'est pas frauduleux ou que le contenu est fiable. Un site trompeur peut également servir HTTPS pour son propre domaine. Le cadenas indique une connexion protégée avec ce serveur, pas une approbation de ses pratiques ou affirmations.

L'authentification TLS web habituelle vérifie principalement le serveur. L'authentification mutuelle, ou mTLS, est une configuration supplémentaire dans laquelle le client présente également un certificat pour s'authentifier. Elle ne doit pas être confondue avec le fonctionnement normal d'HTTPS, dans lequel l'utilisateur ne remet pas nécessairement un certificat personnel.

Pendant une connexion TLS, le chiffrement rend difficile pour les tiers sur la route de lire le contenu protégé et l'intégrité permet de détecter les modifications des données en transit. L'authentification du serveur aide à réduire le risque que le client établisse la connexion avec un imposteur qui ne contrôle pas l'identité certifiée. Ces protections s'appliquent au trajet de la connexion, pas à tous les points par lesquels passent les données.

TLS ne masque pas nécessairement toutes les informations de contexte. Par exemple, l'adresse IP du serveur et d'autres métadonnées réseau peuvent rester visibles ; de plus, le nom du serveur peut être exposé pendant l'établissement dans des configurations qui n'utilisent pas de mécanismes de protection du nom. Il n'empêche pas non plus que le site lui-même, une extension malveillante ou un appareil compromis accèdent aux données une fois qu'elles sont déchiffrées à l'extrémité.

Une connexion HTTPS ne garantit pas non plus le chiffrement de bout en bout entre deux personnes. Le serveur termine la connexion TLS et peut lire les données qu'il reçoit pour fournir le service. Le transport chiffré n'équivaut pas à un contenu inaccessible pour le fournisseur : pour cet objectif, un design de chiffrement de bout en bout est nécessaire dans lequel le service ne contrôle pas les clés de déchiffrement.

openssl s_client permet d'ouvrir une connexion TLS vers un serveur et d'observer des informations de négociation, comme le protocole sélectionné, la suite de chiffrement et les certificats présentés. Pour un domaine de test, une vérification de base est :

openssl s_client -connect example.com:443 -servername example.com -showcerts

L'option -servername envoie le nom via SNI, nécessaire lorsque plusieurs sites partagent la même adresse IP. Sans SNI, le serveur pourrait répondre avec un certificat par défaut qui ne correspond pas au domaine à examiner. Remplacez example.com par le nom que vous administrez ou avez la permission de vérifier.

La sortie n'est pas un verdict de sécurité complet. Examinez le protocole et le chiffrement négociés, la chaîne présentée par le serveur et le code de vérification. La vérification peut dépendre du magasin de confiance de l'installation locale d'OpenSSL ; un résultat correct sur une machine ne prouve pas comment tous les navigateurs ou appareils se comporteront.

Pour demander une connexion spécifique avec TLS 1.3, si la version locale d'OpenSSL le permet, ajoutez -tls1_3 ; pour TLS 1.2, utilisez -tls1_2. Ces options servent à vérifier la compatibilité avec une version, mais une connexion échouée peut être due à la politique du serveur, au réseau ou à l'implémentation locale. Ne modifiez pas la configuration de production sur la base d'un seul test.

Dans le navigateur, le panneau d'informations du site permet d'examiner la connexion et les données du certificat, bien que le chemin exact dépende du navigateur et de sa version. Pour une révision pratique, vérifiez au moins le nom couvert, l'émetteur, la validité et si la page s'est chargée via HTTPS. Les outils de développement peuvent également afficher des informations de sécurité et de requêtes, mais ils ne remplacent pas une révision de la configuration du serveur.

Les échecs de poignée de main sont des symptômes, pas des diagnostics : ils peuvent apparaître lorsque le client et le serveur ne partagent pas une version ou une suite de chiffrement, lorsque le certificat n'est pas valide pour le nom demandé, lorsqu'un certificat intermédiaire manque ou lorsqu'il y a des problèmes de SNI. Une horloge incorrecte peut également faire apparaître un certificat comme non encore valide ou déjà expiré. Identifier la cause évite des « corrections » qui suppriment des protections.

Dans un service web, l'administrateur devrait maintenir des protocoles et algorithmes compatibles avec les clients dont il a réellement besoin, et retirer les options obsolètes selon sa politique de sécurité. TLS 1.3 réduit les options cryptographiques héritées ; TLS 1.2 peut encore être nécessaire pour la compatibilité, mais sa sécurité dépend de la sélection concrète de paramètres. Il ne suffit pas d'activer une version sans revoir l'ensemble complet de la configuration.

Une liste utile pour une première révision est :

• Confirmer que le domaine demandé apparaît dans le certificat et que celui-ci est valide.
• Vérifier si la chaîne de certificats nécessaire est envoyée et si le serveur utilise le bon certificat via SNI.
• Comprendre quelle version TLS et quelle suite de chiffrement sont négociées avec des clients représentatifs.
• Investiguer les journaux du serveur et la sortie d'OpenSSL avant de modifier les politiques.
• Éviter de désactiver la validation du certificat ou de réactiver des protocoles obsolètes comme solution rapide.

Ne désactivez pas la validation pour faire disparaître un avertissement. Si le problème est une chaîne incomplète, un nom incorrect ou un certificat expiré, ignorer la vérification transforme une erreur visible en une connexion moins fiable. La décision pratique est de corriger la cause sur le serveur ou le client, pas d'accepter à l'aveugle une identité qui n'a pas pu être vérifiée.