Certificats, TLS et accès distants
Ce que ce chapitre apporte
- Définir un certificat numérique et ce qu'il atteste.
- Expliquer le rôle d'une autorité de certification et d'une chaîne de confiance.
- Distinguer clé publique et clé privée, et savoir laquelle fait quoi.
- Expliquer ce qu'est une signature numérique et ce qu'elle garantit.
- Décrire le rôle de TLS et ce que HTTPS protège réellement.
- Expliquer le principe d'un VPN et distinguer ses deux usages.
- Relier chaque mécanisme aux propriétés de confidentialité, d'intégrité et d'authentification.
Le problème à résoudre
Chiffrer une communication est facile. Le difficile est ailleurs : savoir à qui l'on parle. Un échange parfaitement chiffré avec un imposteur reste un échange avec un imposteur.
Une clé publique se diffuse librement. Elle sert à chiffrer un message destiné à son propriétaire, ou à vérifier une signature qu'il a produite.
Une clé privée reste secrète. Elle sert à déchiffrer ce qui a été chiffré avec la publique, ou à signer.
Signer avec sa propre clé privée : tout le monde peut vérifier l'identité du signataire. C'est l'authentification.
Même mécanisme, deux sens, deux propriétés différentes. Confondre les deux est l'erreur la plus fréquente sur ce sujet.
Le certificat et la chaîne de confiance
Un certificat numérique est un document électronique qui lie une identité (un nom de serveur, une personne, un équipement) à une clé publique, et qui est signé par une autorité.
Une autorité de certification est l'organisme ou le service qui délivre et signe les certificats.
Une PKI (infrastructure à clés publiques) est l'ensemble qui permet de créer, distribuer, gérer et révoquer ces certificats.
Le certificat ne prouve rien par lui-même. Ce qui vaut, c'est la signature de l'autorité, et la confiance qu'on accorde à cette autorité.
Autorite racine (auto-signee, presente dans le
| signe magasin de confiance du poste)
Autorite intermediaire
| signe
srv-web.ardexia.lan (porte la cle publique du serveur)
Le navigateur remonte la chaîne. S'il arrive à une autorité qu'il connaît et que chaque signature est valide et qu'aucun certificat n'est expiré ni révoqué, il fait confiance.
La deuxième est celle qui produit les incidents : un certificat expire à date fixe, personne ne surveille l'échéance, et le service tombe un dimanche. C'est une panne parfaitement prévisible, et c'est pourtant l'une des plus courantes.
Le seuil d'alerte se règle à trente jours au moins, parce qu'un renouvellement suppose parfois une validation externe.
La signature numérique
Une signature numérique garantit l'origine et l'intégrité d'une information. On calcule l'empreinte du message par une fonction de hachage, puis on chiffre cette empreinte avec sa clé privée.
Pour vérifier : on déchiffre la signature avec la clé publique, on recalcule l'empreinte du message reçu, et on compare.
Elle ne garantit pas la confidentialité : un document signé reste lisible par tous. Pour qu'il soit à la fois authentique et secret, il faut signer et chiffrer.
TLS et HTTPS
Le certificat ne sert qu'à la première moitié de l'échange. Une fois le secret de session établi, il ne circule plus, et c'est ce qui protège les échanges passés même si la clé du serveur est découverte plus tard.
TLS est le protocole qui sécurise une communication entre deux systèmes. HTTPS est simplement HTTP transporté par TLS.
La négociation initiale enchaîne quatre étapes, et l'ordre compte :
- Le client annonce les algorithmes qu'il sait employer.
- Le serveur présente son certificat, que le client vérifie par la chaîne de confiance.
- Les deux conviennent d'une clé de session partagée, par un échange asymétrique.
- Toute la suite de l'échange est chiffrée symétriquement avec cette clé de session.
La troisième étape est celle qu'on saute d'ordinaire, et elle n'a rien d'évident : comment deux machines qui ne se connaissaient pas s'accordent-elles sur un secret commun, sans jamais le faire circuler ?
Chacun tire un secret et n'envoie que sa moitié publique. Client et serveur choisissent chacun une valeur aléatoire, en dérivent une valeur publique correspondante, et s'échangent uniquement ces valeurs publiques. C'est un échange de type Diffie-Hellman, aujourd'hui sur courbes elliptiques.
Chacun combine sa part privée avec la part publique de l'autre. La construction est telle que les deux calculs, pourtant menés à partir d'informations différentes, aboutissent à la même valeur. Un observateur qui a vu passer les deux valeurs publiques ne peut pas la retrouver.
Le certificat sert à signer, pas à chiffrer. Le serveur signe sa contribution avec la clé privée associée à son certificat. Le client vérifie cette signature, ce qui lui prouve qu'il négocie bien avec le titulaire du certificat et non avec un intermédiaire. Le secret commun est ensuite dérivé en clés symétriques.
Le schéma ci-dessous déroule cet enchaînement. Le temps descend, et l'endroit où la ligne bascule en chiffrement symétrique se lit à la place de la note.
Deux choses se lisent sur ce schéma et sur aucune liste d'étapes. Le secret commun est calculable avant que le certificat n'ait été présenté : la confidentialité et l'authentification sont deux opérations séparées, menées dans cet ordre. Et le certificat n'apparaît que dans un seul sens, du serveur vers le client, ce qui rappelle qu'il sert à prouver une identité, jamais à transporter un secret.
Avec un accord de clé, la clé privée du serveur ne sert qu'à signer sur l'instant. La compromettre demain permet de se faire passer pour le serveur, ce qui est déjà grave, mais ne donne aucun moyen de déchiffrer les échanges enregistrés hier. Cette propriété s'appelle la confidentialité persistante, et c'est pour l'obtenir toujours que la variante ancienne a été retirée de TLS 1.3.
TLS paie le coût de l'asymétrique une seule fois, au début, pour se mettre d'accord sur une clé de session, puis bascule en symétrique pour tout le reste. On obtient la souplesse de l'un et la vitesse de l'autre.
Le cadenas atteste « la connexion va bien à
ce-domaine.fr ». Il n'atteste pas que ce-domaine.fr soit la banque attendue. C'est la confusion sur laquelle repose une grande partie de l'hameçonnage.
Les accès distants
Un VPN (réseau privé virtuel) établit une liaison sécurisée à travers un réseau qui ne l'est pas, typiquement Internet.
Un tunnel est le canal chiffré ainsi créé : les paquets sont encapsulés et chiffrés d'un bout à l'autre.
Deux usages, souvent confondus :
| Usage | Ce qu'il relie | Cas Ardexia |
|---|---|---|
| Site à site | deux réseaux d'entreprise | Beauvais et Amiens, en permanence |
| Nomade | un poste isolé au réseau | un préleveur en tournée |
D'où les précautions qui accompagnent tout VPN d'accès : authentification à plusieurs facteurs, vérification de l'état du poste avant admission, et accès limité aux seules ressources nécessaires plutôt qu'au réseau entier. C'est le moindre privilège du chapitre 6, appliqué au réseau.
Les quatre propriétés, et ce qui les assure
C'est la synthèse à savoir restituer, parce qu'elle relie tout le chapitre.
| Propriété | Ce qu'elle garantit | Mécanisme |
|---|---|---|
| Confidentialité | seuls les autorisés lisent | chiffrement |
| Intégrité | le message n'a pas été modifié | hachage, signature |
| Authentification | l'interlocuteur est bien celui qu'il prétend | certificat, signature |
| Non-répudiation | l'auteur ne peut nier avoir signé | signature avec clé privée |
La non-répudiation prolonge l'authentification sur le terrain de la responsabilité. Vérifier une signature établit qu'elle a été produite avec une clé privée déterminée ; si cette clé est réputée sous la maîtrise exclusive d'une personne, celle-ci ne peut plus soutenir n'être pas l'auteur de l'acte signé.
Une clé privée stockée dans un fichier sur un poste partagé n'apporte aucune non-répudiation, quelle que soit la robustesse de l'algorithme. C'est la différence entre les trois premières propriétés du tableau, qui sont techniques, et la quatrième, qui est technique et organisationnelle.
Un message signé est authentique et lisible par tous : intégrité et authentification sans confidentialité.
C'est pourquoi TLS combine les trois, et pourquoi toute analyse commence par « quelle propriété cherche-t-on à garantir ? ».
Exercices type
Le site interne affiche un avertissement de sécurité. Quelles causes possibles ?
Quatre, à vérifier dans cet ordre :
Certificat expiré. La plus fréquente, et la plus facile à confirmer : la date figure dans le certificat.
Autorité inconnue du poste. Cas courant avec une autorité interne dont le certificat racine n'a pas été déployé sur les postes, ce qui se fait par stratégie de groupe.
Nom qui ne correspond pas. Le certificat est émis pour srv-web.ardexia.lan et l'on accède par l'adresse IP, ou par un autre alias.
Certificat révoqué, si l'autorité l'a invalidé avant son échéance.
Ce qu'il ne faut pas faire : demander aux utilisateurs de cliquer sur « continuer malgré tout ». On leur apprend alors à ignorer l'avertissement, et le jour où il est justifié, ils l'ignoreront aussi.
Chiffrer ou signer : que fait-on pour envoyer un devis confidentiel ?
Les deux, et pas dans n'importe quel sens.
Chiffrer avec la clé publique du destinataire : lui seul pourra lire. C'est la confidentialité.
Signer avec sa propre clé privée : il pourra vérifier que le devis vient bien de son auteur et n'a pas été modifié. C'est l'authentification et l'intégrité.
L'erreur classique consiste à intervertir les clés. Chiffrer avec sa propre clé publique produit un document que soi-même seulement peut lire, ce qui n'a aucun intérêt. Signer avec la clé publique du destinataire n'est pas possible : on ne signe qu'avec une clé privée, et on n'a que la sienne.
Pourquoi TLS n'utilise-t-il pas uniquement du chiffrement asymétrique ?
Parce que ce serait beaucoup trop lent. Le chiffrement asymétrique coûte plusieurs ordres de grandeur de plus que le symétrique par octet traité.
TLS s'en sert donc là où il est irremplaçable : authentifier le serveur et convenir d'une clé de session sans l'avoir échangée au préalable.
Ensuite, tout le trafic passe en symétrique avec cette clé de session, qui n'existe que le temps de la connexion.
C'est la même architecture que le chiffrement d'un disque ou d'une archive : une clé symétrique fait le travail, et l'asymétrique sert uniquement à la transmettre.
Un préleveur en tournée doit accéder au serveur de fichiers. VPN ou publication sur Internet ?
VPN, sans hésitation.
Publier un partage de fichiers directement sur Internet expose un protocole qui n'a jamais été conçu pour cela, et qui est la cible privilégiée des rançongiciels.
Le VPN ne rend pas le poste sûr pour autant. Il faut l'accompagner : authentification à plusieurs facteurs, poste à jour et vérifié avant admission, et surtout accès restreint aux seules ressources nécessaires.
Un VPN qui donne accès à tout le réseau interne transforme chaque poste nomade en porte d'entrée. Le tunnel chiffre, il ne trie pas.
Faut-il une autorité de certification interne chez Ardexia ?
Cela dépend de l'usage, et les deux réponses coexistent en général.
Pour les services exposés sur Internet, non : il faut une autorité publique, sans quoi les navigateurs des visiteurs afficheront un avertissement, puisqu'ils ne connaissent pas l'autorité d'Ardexia.
Pour les services internes, une autorité interne se justifie : elle délivre gratuitement autant de certificats qu'on veut, pour les serveurs internes, les postes, l'authentification par carte.
La condition à ne pas négliger : le certificat racine interne doit être déployé dans le magasin de confiance de tous les postes, ce qui se fait par stratégie de groupe. Et la clé privée de cette autorité doit être protégée à la hauteur de ce qu'elle permet : quiconque la détient peut se faire passer pour n'importe quel serveur de l'entreprise.
Le certificat du serveur web expire dans trois jours. Que se passe-t-il si on ne fait rien ?
Le jour de l'expiration, chaque visiteur reçoit un avertissement de sécurité bloquant. Les navigateurs récents rendent le contournement volontairement pénible, et les applications qui appellent le service en machine à machine, elles, refusent simplement la connexion, sans avertissement ni contournement possible.
Le service est donc en panne, alors que le serveur fonctionne parfaitement. C'est exactement la situation décrite au chapitre 7 : un tableau de bord technique tout vert, et un service indisponible.
Ce que cet incident révèle, au-delà du certificat : l'absence d'une sonde d'expiration. Le renouvellement se traite en une heure, l'incident se serait évité en dix minutes de supervision.
Vérification
1.Que garantit le cadenas d'un navigateur ?
2.Combien de vérifications un navigateur mène-t-il sur une chaîne de certificats ?
3.Un certificat expiré compromet laquelle des trois propriétés ?
4.Un accès distant par VPN protège-t-il le réseau interne ?
La méthode
- Nommer la propriété visée avant de choisir un mécanisme : confidentialité, intégrité, authentification ou non-répudiation.
- Vérifier le sens des clés : publique du destinataire pour chiffrer, privée de l'expéditeur pour signer.
- Contrôler les trois conditions d'une chaîne : autorité connue, période de validité, absence de révocation.
- Superviser les dates d'expiration avec une alerte à trente jours au moins.
- Ne jamais apprendre aux utilisateurs à passer outre un avertissement de certificat.
- Déployer le certificat racine interne par stratégie de groupe avant de publier des services internes en HTTPS.
- Restreindre ce que le VPN donne, et exiger une authentification à plusieurs facteurs.
Synthèse
- Clé publique : chiffrer pour quelqu'un, vérifier sa signature. Clé privée : déchiffrer, signer.
- Un certificat lie une identité à une clé publique, et vaut par la signature de l'autorité.
- Une chaîne est acceptée si l'autorité est connue, si tous les certificats sont dans leur validité, et si aucun n'est révoqué.
- Une signature garantit origine et intégrité, jamais la confidentialité.
- TLS authentifie par certificat, convient d'une clé de session en asymétrique, puis chiffre en symétrique.
- Le cadenas atteste le domaine, pas l'honnêteté du site.
- Un VPN étend le périmètre : un poste compromis le devient à l'intérieur. Moindre privilège et authentification forte.
- Confidentialité, intégrité, authentification, non-répudiation : quatre propriétés distinctes, aucune ne découle d'une autre.
Mettre en pratique
Remonter une chaîne de confiance, et ce qu'un certificat expiré compromet vraiment.
- Pourquoi la chaîne est refuséeNiveau 3
- Trois vérifications, pas uneNiveau 2
- Ce que TLS apporte, et à quiNiveau 3