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 que c'est bien vous. 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 magasin de confiance du poste)
| signe
Autorite intermediaire
| signe
Certificat de srv-web.neolink.local (contient 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
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.
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 « vous parlez bien à
ce-domaine.fr ». Il n'atteste pas que ce-domaine.fr soit votre banque. 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 NeoLink |
|---|---|---|
| Site à site | deux réseaux d'entreprise | Lyon et Paris, en permanence |
| Nomade | un poste isolé au réseau | un commercial en déplacement |
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 |
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.neolink.local 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 vous 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 commercial en déplacement 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 NeoLink ?
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é de NeoLink.
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.
La méthode
- Nomme la propriété visée avant de choisir un mécanisme : confidentialité, intégrité, authentification ou non-répudiation.
- Vérifie le sens des clés : publique du destinataire pour chiffrer, privée de l'expéditeur pour signer.
- Contrôle les trois conditions d'une chaîne : autorité connue, période de validité, absence de révocation.
- Supervise les dates d'expiration avec une alerte à trente jours au moins.
- N'apprends jamais aux utilisateurs à passer outre un avertissement de certificat.
- Déploie le certificat racine interne par stratégie de groupe avant de publier des services internes en HTTPS.
- Restreins ce que le VPN donne, et exige une authentification à plusieurs facteurs.
En résumé
- 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.
Et ensuite ? Le bloc est bouclé. NeoLink a une cartographie, un annuaire organisé, des droits maîtrisés, des sauvegardes testées, un périmètre segmenté, une infrastructure supervisée, des opérations scriptées et des échanges authentifiés. Ce qui relie ces neuf chapitres n'est pas une technologie : c'est une même exigence, celle de pouvoir répondre à une question sur son propre système d'information, et de le prouver.