Comment fonctionne vraiment SSL?
Comment fonctionne SSL?
Où le certificat est-il installé sur le client (ou le navigateur?) Et le serveur (ou le serveur Web?)?
Comment le processus de confiance/cryptage/authentification démarre-t-il lorsque vous entrez l'URL dans le navigateur et obtenez la page du serveur?
Comment le protocole HTTPS reconnaît-il le certificat? Pourquoi HTTP ne peut-il pas fonctionner avec des certificats alors que ce sont les certificats qui font tout le travail de confiance/cryptage/authentification?
Remarque: J'ai écrit ma réponse originale très hâtivement, mais depuis lors, cela s'est transformé en une question/réponse assez populaire, donc je l'ai un peu développée et rendue plus précise.
Capacités TLS
"SSL" est le nom le plus souvent utilisé pour faire référence à 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, donc j'utiliserai TLS dans ma réponse. De nos jours, il y a de fortes chances que presque toutes vos connexions sécurisées sur le Web utilisent vraiment TLS, pas SSL.
TLS a plusieurs capacités:
- Chiffrez les données de votre couche d'application. (Dans votre cas, le protocole de couche application est HTTP.)
- Authentifiez le serveur auprès du client.
- Authentifiez le client auprès du serveur.
# 1 et # 2 sont très courants. # 3 est moins courant. Vous semblez vous concentrer sur # 2, donc 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é délivré
- Quand il expire
- Qui l'a délivré
- Etc.
Vous pouvez obtenir la confidentialité (n ° 1 ci-dessus) en utilisant la clé publique incluse dans le certificat pour crypter les messages qui ne peuvent être décrypté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 de ne pas nous embrouiller 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 si cet adversaire modifie le certificat qui vous est présenté et insère sa propre clé publique ou change tout autre détail important? Si cela se produisait, l'adversaire pourrait intercepter et modifier tous les messages que vous pensiez être cryptés en toute sécurité.
Pour éviter cette attaque même, le certificat est signé cryptographiquement par la clé privée de quelqu'un d'autre de telle manière que la signature peut être vérifiée par quiconque possède la clé publique correspondante. Appelons cette paire de clés KP2, pour préciser qu'il ne s'agit pas des 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?
Simplifiant un peu trop, une autorité de certification crée KP2, et ils vendent le service d'utiliser leur 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 sauf Verisign n'a accès à cette clé privée, aucun de nous ne peut forger 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 la distribuer de cette façon? Cela semble un peu fou au début, mais en fait, c'est exactement comme ça que ça fonctionne. Poursuivant avec l'exemple 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?!
Enfin, pas si vite. J'ai dû obtenir le certificat Verisign de quelque part . Et si quelqu'un usurpe le certificat Verisign et y met 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 d'homme au milieu.
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 ne concerne que les tortues/certificats. Où ça s'arrête?
Puisque 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 m'arrête un instant pendant que vous ramassez les morceaux de matière cérébrale de votre tête en train d'exploser. 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écursion infinie, mais cela ne résout pas le problème d'authentification. Tout le monde peut créer un certificat auto-signé qui dit quoi que ce soit dessus, tout comme je peux créer un faux diplôme de Princeton qui dit que je me suis spécialisé en politique, en physique théorique et en coups de pied, puis que je signe mon nom en bas.
La solution [quelque peu excitante] à 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. Quel que soit 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 oui, alors 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 embaucher 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 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 exploitent 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 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 ensuite 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 votre ordinateur de l'employé. Dans ces différents cas, le trafic que vous attendez à être "sécurisé" est en fait complètement visible/modifiable par 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 conformément à la norme X.509 . X.509 est basé sur ASN.1 ("Notation de syntaxe abstraite # 1"), ce qui signifie qu'il n'est pas un format de données binaires. 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] Dans la pratique, le protocole bascule en fait vers un chiffrement symétrique, mais c'est un détail qui n'est pas pertinent pour votre question.
[3] Je présume que l'AC 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 pouvais trouver une 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 dans les centaines d'autorités de certification à travers le monde n'est pas très claire.
[4] Voir Mozilla's liste des CA de confiance .
HTTPS est une combinaison de [~ # ~] http [~ # ~] et SSL (Secure Socket Layer) pour fournir une communication cryptée entre le client (navigateur) et le serveur Web (l'application est hébergée ici).
Pourquoi est-il nécessaire?
HTTPS crypte les données transmises du navigateur au serveur via le réseau. Ainsi, personne ne peut renifler les données pendant la transmission.
Comment la connexion HTTPS est-elle établie entre le navigateur et le serveur Web?
- Le navigateur essaie de se connecter à https://payment.com .
- le serveur de payment.com envoie un certificat au navigateur. Ce certificat inclut la clé publique du serveur de payment.com et certaines preuves que cette clé publique appartient réellement à payment.com.
- Le navigateur vérifie le certificat pour confirmer qu'il possède la clé publique appropriée pour payment.com.
- Le navigateur choisit une nouvelle clé symétrique aléatoire K à utiliser pour sa connexion au serveur payment.com. Il chiffre K sous la clé publique de payment.com.
- payment.com décrypte K à l'aide de sa clé privée. Maintenant, le navigateur et le serveur de paiement connaissent K, mais personne d'autre ne le sait.
- Chaque fois que le navigateur souhaite envoyer quelque chose à payment.com, il le chiffre sous K; le serveur de payment.com le déchiffre à réception. Chaque fois que le serveur de payment.com souhaite envoyer quelque chose à votre navigateur, il le chiffre sous K.
Ce flux peut être représenté par le diagramme suivant: 
J'ai écrit un petit billet de blog qui discute brièvement du processus. N'hésitez pas à jeter un œil.
Un petit extrait du même est comme suit:
"Le client fait une demande au serveur via HTTPS. Le serveur envoie une copie de son certificat SSL + clé publique. Après avoir vérifié l'identité du serveur avec son magasin de CA de confiance local, le client génère une clé de session secrète, la crypte en utilisant le serveur public clé et l'envoie. Le serveur déchiffre la clé de session secrète à l'aide de sa clé privée et envoie un accusé de réception au client. Canal sécurisé établi. "
Mehaase l'a déjà expliqué en détails. J'ajouterai mes 2 cents à cette série. J'ai de nombreux articles de blog autour de la négociation et des certificats SSL. Bien que la plupart de ces informations tournent autour de IIS serveur Web, la publication est toujours pertinente pour la prise de contact SSL/TLS en général. En voici quelques-unes pour référence:
Ne pas traiter [~ # ~] certificats [~ # ~] & [~ # ~] ssl [~ # ~] comme un sujet. Traitez-les comme 2 sujets différents, puis essayez de voir qui ils travaillent ensemble. Cela vous aidera à répondre à la question.
Etablir la confiance entre les parties communicantes via le magasin de certificats
La communication SSL/TLS fonctionne uniquement sur la base de la confiance. Chaque ordinateur (client/serveur) sur Internet a une liste de CA racine et CA intermédiaire qu'il gère. Celles-ci sont périodiquement mises à jour. Au cours de la négociation SSL, ceci est utilisé comme référence pour établir la confiance. Par exemple, lors d'une prise de contact SSL, lorsque le client fournit un certificat au serveur. Le serveur essaiera de vérifier si l'autorité de certification qui a émis le certificat est présente dans sa liste d'autorités de certification. Lorsqu'il ne peut pas le faire, il déclare qu'il n'a pas pu effectuer la vérification de la chaîne de certificats. (Ceci fait partie de la réponse. Il examine également [~ # ~] aia [~ # ~] pour cela.) Le client fait également une vérification similaire pour le certificat de serveur qu'il reçoit dans Server Hello. Sous Windows, vous pouvez voir les magasins de certificats pour le client et le serveur via PowerShell. Exécutez ce qui suit à partir d'une console PowerShell.
Cert PS:> ls Emplacement: CurrentUser StoreNames: {TrustedPublisher, ClientAuthIssuer, Root, UserDS ...}
Emplacement: LocalMachine StoreNames: {TrustedPublisher, ClientAuthIssuer, Remote Desktop, Root ...}
Les navigateurs comme Firefox et Opera ne dépendent pas du système d'exploitation sous-jacent pour la gestion des certificats. Ils gèrent leurs propres magasins de certificats distincts.
La négociation SSL utilise à la fois la cryptographie symétrique et à clé publique. L'authentification du serveur se produit par défaut. L'authentification client est facultative et dépend si le point de terminaison du serveur est configuré pour authentifier le client ou non. Référez-vous à mon blog comme je l'ai expliqué en détail.
Enfin pour cette question
Comment le protocole HTTPS reconnaît-il le certificat? Pourquoi HTTP ne peut-il pas fonctionner avec des certificats alors que ce sont les certificats qui font tout le travail de confiance/cryptage/authentification?
Les certificats sont simplement un fichier dont le format est défini par la norme X.509 . Il s'agit d'un document électronique qui prouve l'identité d'une partie communicante. HTTPS = HTTP + SSL est un protocole qui définit les directives sur la façon dont 2 parties doivent communiquer entre elles.
PLUS D'INFORMATIONS
- Afin de comprendre les certificats, vous devrez comprendre ce que sont les certificats et lire également la gestion des certificats. C'est important.
- Une fois que cela est compris, passez à la négociation TLS/SSL. Vous pouvez vous référer aux RFC pour cela. Mais ce sont des squelettes qui définissent les lignes directrices. Il existe plusieurs articles de blog, dont le mien, qui expliquent cela en détail.
Si l'activité ci-dessus est effectuée, vous aurez une bonne compréhension des certificats et SSL.