Remarque: j'ai écrit ma réponse originale très rapidement, mais depuis lors, cela est devenu une question / réponse assez populaire, donc je l'ai un peu élargie et rendue plus précise.
Capacités TLS
«SSL» est le nom le plus souvent utilisé pour désigner ce protocole, mais SSL fait spécifiquement référence au protocole propriétaire conçu par Netscape au milieu des années 90. «TLS» est une norme IETF basée sur SSL, j'utiliserai donc TLS dans ma réponse. De nos jours, il est fort probable que presque toutes vos connexions sécurisées sur le Web utilisent vraiment TLS, pas SSL.
TLS a plusieurs capacités:
- Cryptez vos données de couche d'application. (Dans votre cas, le protocole de la couche application est HTTP.)
- Authentifiez le serveur auprès du client.
- Authentifiez le client auprès du serveur.
Les numéros 1 et 2 sont très courants. Le n ° 3 est moins courant. Vous semblez vous concentrer sur le n ° 2, alors je vais expliquer cette partie.
Authentification
Un serveur s'authentifie auprès d'un client à l'aide d'un certificat. Un certificat est un blob de données [1] qui contient des informations sur un site Web:
- Nom de domaine
- Clé publique
- L'entreprise qui en est propriétaire
- Quand il a été publié
- Quand il expire
- Qui l'a émis
- Etc.
Vous pouvez atteindre la confidentialité (n ° 1 ci-dessus) en utilisant la clé publique incluse dans le certificat pour chiffrer les messages qui ne peuvent être déchiffrés que par la clé privée correspondante, qui doit être stockée en toute sécurité sur ce serveur. [2] Appelons cette paire de clés KP1, afin que nous ne soyons pas confus plus tard. Vous pouvez également vérifier que le nom de domaine sur le certificat correspond au site que vous visitez (n ° 2 ci-dessus).
Mais que se passe-t-il si un adversaire peut modifier les paquets envoyés vers et depuis le serveur, et que se passe-t-il si cet adversaire modifie le certificat qui vous est présenté et insère sa propre clé publique ou modifie d'autres détails importants? Si cela se produisait, l'adversaire pourrait intercepter et modifier tous les messages que vous pensiez être cryptés de manière sécurisée.
Pour éviter cette attaque, le certificat est signé cryptographiquement par la clé privée de quelqu'un d'autre de telle sorte que la signature puisse être vérifiée par quiconque possède la clé publique correspondante. Appelons cette paire de clés KP2, pour préciser que ce ne sont pas les mêmes clés que celles utilisées par le serveur.
Autorités de certification
Alors, qui a créé KP2? Qui a signé le certificat?
En simplifiant un peu trop , une autorité de certification crée KP2 et vend le service d'utilisation de sa clé privée pour signer des certificats pour d'autres organisations. Par exemple, je crée un certificat et je paie une entreprise comme Verisign pour le signer avec sa clé privée. [3] Étant donné que personne d'autre que Verisign n'a accès à cette clé privée, aucun de nous ne peut falsifier cette signature.
Et comment pourrais-je personnellement obtenir la clé publique dans KP2 afin de vérifier cette signature?
Eh bien, nous avons déjà vu qu'un certificat peut contenir une clé publique - et les informaticiens adorent la récursivité - alors pourquoi ne pas mettre la clé publique KP2 dans un certificat et le distribuer de cette façon? Cela semble un peu fou au début, mais en fait, c'est exactement comme cela que cela fonctionne. Poursuivant l'exemple de Verisign, Verisign produit un certificat qui inclut des informations sur qui ils sont, quels types de choses ils sont autorisés à signer (autres certificats) et leur clé publique.
Maintenant, si j'ai une copie de ce certificat Verisign, je peux l'utiliser pour valider la signature sur le certificat du serveur pour le site Web que je souhaite visiter. Facile, non?!
Eh bien, pas si vite. Je devais obtenir le certificat Verisign de quelque part . Que faire si quelqu'un usurpe le certificat Verisign et y place sa propre clé publique? Ensuite, ils peuvent forger la signature sur le certificat du serveur, et nous sommes de retour là où nous avons commencé: une attaque de type man-in-the-middle.
Chaînes de certificats
En continuant à penser de manière récursive, nous pourrions bien sûr introduire un troisième certificat et une troisième paire de clés (KP3) et l'utiliser pour signer le certificat Verisign. Nous appelons cela une chaîne de certificats: chaque certificat de la chaîne est utilisé pour vérifier le certificat suivant. J'espère que vous pouvez déjà voir que cette approche récursive n'est que des tortues / certificats jusqu'au bout. Où ça s'arrête?
Comme nous ne pouvons pas créer un nombre infini de certificats, la chaîne de certificats doit évidemment s'arrêter quelque part , et cela se fait en incluant un certificat dans la chaîne qui est auto-signé .
Je vais faire une pause pendant un moment pendant que vous ramassez les morceaux de matière cérébrale de votre tête qui explose. Auto-signé?!
Oui, à la fin de la chaîne de certificats (alias la «racine»), il y aura un certificat qui utilise sa propre paire de clés pour se signer. Cela élimine le problème de récursivité infinie, mais ne résout pas le problème d'authentification. N'importe qui peut créer un certificat auto-signé qui dit n'importe quoi, tout comme je peux créer un faux diplôme de Princeton qui dit que je suis triple spécialisation en politique, en physique théorique et en appliquant des coups de pied, puis signer mon propre nom en bas.
La solution [assez peu intéressante] à ce problème consiste simplement à choisir un ensemble de certificats auto-signés auxquels vous faites explicitement confiance. Par exemple, je pourrais dire: «Je fais confiance à ce certificat auto-signé Verisign».
Avec cette confiance explicite en place, je peux maintenant valider toute la chaîne de certificats. Peu importe le nombre de certificats dans la chaîne, je peux valider chaque signature jusqu'à la racine. Lorsque j'arrive à la racine, je peux vérifier si ce certificat racine est un certificat auquel je fais explicitement confiance. Si tel est le cas, je peux faire confiance à toute la chaîne.
Confiance conférée
L'authentification dans TLS utilise un système de confiance conférée . Si je veux engager un mécanicien automobile, je ne peux faire confiance à aucun mécanicien aléatoire que je trouve. Mais peut-être que mon ami se porte garant d'un mécanicien en particulier. Puisque je fais confiance à mon ami, je peux faire confiance à ce mécanicien.
Lorsque vous achetez un ordinateur ou téléchargez un navigateur, il est livré avec quelques centaines de certificats racine auxquels il fait explicitement confiance. [4] Les entreprises qui possèdent et gèrent ces certificats peuvent conférer cette confiance à d'autres organisations en signant leurs certificats.
C'est loin d'être un système parfait. Parfois, une autorité de certification peut émettre un certificat par erreur. Dans ces cas, le certificat peut devoir être révoqué. La révocation est délicate car le certificat émis sera toujours cryptographiquement correct; un protocole hors bande est nécessaire pour savoir quels certificats précédemment valides ont été révoqués. En pratique, certains de ces protocoles ne sont pas très sécurisés et de nombreux navigateurs ne les vérifient pas de toute façon.
Parfois, une autorité de certification entière est compromise. Par exemple, si vous deviez pénétrer par effraction dans Verisign et voler leur clé de signature racine, vous pourriez usurper n'importe quel certificat dans le monde. Notez que cela n'affecte pas seulement les clients Verisign: même si mon certificat est signé par Thawte (un concurrent de Verisign), cela n'a pas d'importance. Mon certificat peut toujours être falsifié à l'aide de la clé de signature compromise de Verisign.
Ce n'est pas seulement théorique. C'est arrivé dans la nature. DigiNotar a été piraté et a par la suite fait faillite. Comodo a également été piraté , mais inexplicablement, ils restent en activité à ce jour.
Même lorsque les autorités de certification ne sont pas directement compromises, il existe d'autres menaces dans ce système. Par exemple, un gouvernement utilise la contrainte légale pour obliger une autorité de certification à signer un faux certificat. Votre employeur peut installer son propre certificat CA sur l'ordinateur de votre employé. Dans ces différents cas, le trafic que vous attendez d'être «sécurisé» est en fait complètement visible / modifiable pour l'organisation qui contrôle ce certificat.
Certains remplacements ont été suggérés, notamment Convergence , TACK et DANE .
Notes de fin
[1] Les données du certificat TLS sont formatées selon la norme X.509 . X.509 est basé sur ASN.1 ("Abstract Syntax Notation # 1"), ce qui signifie qu'il ne s'agit pas d' un format de données binaire. Par conséquent, X.509 doit être codé dans un format binaire. DER et PEM sont les deux encodages les plus courants que je connaisse.
[2] En pratique, le protocole bascule en fait sur un chiffrement symétrique, mais c'est un détail qui n'est pas pertinent pour votre question.
[3] On peut supposer que l'autorité de certification valide réellement qui vous êtes avant de signer votre certificat. S'ils ne l'ont pas fait, je pourrais simplement créer un certificat pour google.com et demander à une autorité de certification de le signer. Avec ce certificat, je pourrais gérer n'importe quelle connexion "sécurisée" à google.com. Par conséquent, l'étape de validation est un facteur très important dans le fonctionnement d'une autorité de certification. Malheureusement, la rigueur de ce processus de validation n'est pas très claire dans les centaines de CA à travers le monde.
[4] Voir la liste de Mozilla des autorités de certification de confiance .
