Comment fonctionne SSL vraiment travailler?

Note: j'ai écrit ma réponse originale à cette question très à la hâte, mais depuis, cela s'est transformé en un assez populaire de question/réponse, donc j'ai élargi un peu de plus en plus précis.

TLS Capacités

"SSL" est le nom qui est le plus souvent utilisé pour se référer à ce protocole, mais SSL est fait spécifiquement référence au protocole propriétaire conçu par Netscape dans les années 90. "TLS" est une norme IETF qui est basé sur le protocole SSL, donc je vais utiliser TLS dans ma réponse. Ces jours-ci, les chances sont que la quasi-totalité de vos connexions sécurisées sur le web sont vraiment à l'aide de TLS, pas de SSL.

TLS a plusieurs capacités:

1. Crypter vos données de la couche application. (Dans votre cas, le protocole de la couche application est HTTP.)
2. Authentifier le serveur vers le client.
3. Authentifier le client vers le serveur.

#1 et #2 sont très fréquents. #3 est moins commun. Vous semblez être en se concentrant sur le #2, je vais donc expliquer qu'une partie.

Authentification

Un serveur s'authentifie auprès d'un client à l'aide d'un certificat. Un certificat est un tas de données[1] qui contient des informations sur un site web:

• Nom de domaine
• Clé publique
• L'entreprise qui la détient
• Lorsqu'il a été émis
• Quand il expire
• Qui a délivré
• Etc.

Vous pouvez atteindre le niveau de confidentialité (#1 ci-dessus) en utilisant la clé publique incluse dans le certificat pour crypter des messages qui ne peuvent être déchiffrées que par la clé privée correspondante, qui doivent être stockés en toute sécurité sur le serveur.[2] appelons cette paire de clés KP1, afin de ne pas se confondre plus tard. Vous pouvez également vérifier que le nom de domaine sur le certificat correspond au site que vous visitez (#2 ci-dessus).

Mais si un adversaire pourrait modifier les paquets envoyés vers et depuis le serveur, et que si l'adversaire a modifié le certificat qui vous ont été présentés avec et inséré leur propre clé publique ou modifié d'autres détails importants? Si cela arrivait, l'adversaire peut intercepter et modifier tous les messages que vous avez pensé de manière sécurisée cryptée.

Pour empêcher cette attaque, le certificat est signé cryptographiquement par quelqu'un d'autre de la clé privée d'une manière telle que la signature peut être vérifiée par une personne qui a la clé publique correspondante. Appelons cette paire de clés KP2, de préciser que ce ne sont pas les mêmes touches que le serveur utilise.

Autorités De Certification

Donc, qui a créé KP2? Qui a signé le certificat?

Trop simplifier un peu, un autorité de certification crée KP2, et ils vendent le service de l'aide de sa clé privée pour signer des certificats pour d'autres organisations. Par exemple, j'ai créer un certificat et j'ai payer une entreprise comme Verisign pour qu'il la signe avec sa clé privée.[3] Puisque personne n'mais Verisign a accès à cette clé privée, aucun de nous ne peut forger cette signature.

Et comment personnellement, je mettre la main sur la clé publique dans KP2 afin de vérifier que la signature?

Eh bien, nous avons déjà vu qu'un certificat peut contenir une clé publique et chercheurs en informatique de l'amour de la récursivité — alors, pourquoi ne pas mettre le KP2 clé publique dans un certificat et de distribuer cette façon? Cela semble un peu fou au premier abord, mais en fait, c'est exactement comment il fonctionne. En continuant avec l'exemple Verisign Verisign a produit un certificat qui contient des informations à propos de qui ils sont, quels sont les types de choses qu'ils sont autorisés à signer (autres certificats), et de la clé publique.

Maintenant, si j'ai une copie de ce certificat Verisign, je peux l'utiliser pour valider la signature sur le certificat de serveur pour le site, je veux visiter. Facile, droit?!

Bien, pas si vite. J'ai eu pour obtenir le certificat Verisign de quelque part. Que faire si quelqu'un usurpe le certificat Verisign et met leur propre clé publique, là? Ensuite, ils peuvent forger la signature sur le certificat du serveur, et nous sommes de retour là où nous avons commencé: un man-in-the-middle attack.

Chaînes De Certificats

Continuant à penser de manière récursive, nous pourrions introduire un troisième certificat et une troisième paire de clés (KP3) et l'utiliser pour signer la Verisign certifcate. Nous appelons cela un certificat de la chaîne: chaque certificat de la chaîne est utilisée pour vérifier le certificat suivant. J'espère que vous pouvez déjà voir que cette approche récursive est juste tortues/certificats tout le chemin vers le bas. Où faut-il s'arrêter?

Puisque nous ne pouvons pas créer un nombre infini de certificats, le certificat de la chaîne a évidemment pour arrêter quelque part, et c'est, par exemple, un certificat de la chaîne qui est auto-signé.

Je vais mettre en pause un instant, le temps de ramasser les morceaux de cerveau de la matière à partir de votre tête explose. Auto-signé?!

Oui, à la fin de la chaîne de certificats (un.k.un. la "racine"), il y aura un certificat qui utilise sa propre paire de clés de signer lui-même. Ceci élimine la récursivité infinie problème, mais il ne résout pas le problème de l'authentification. N'importe qui peut créer un certificat auto-signé qui ne dit rien sur elle, tout comme je peux créer un faux diplôme de Princeton qui dit que je triple s'est spécialisé dans la politique, la physique théorique et appliquée butt-kicking et ensuite signer mon propre nom, au fond.

L' [un peu fade] solution à ce problème est de choisir un ensemble de certificats auto-signés de manière explicite la confiance. Par exemple, je pourrais dire, "je confiance ce Verisign certificat auto-signé."

Avec cette approbation explicite en place, maintenant je peux valider l'ensemble de la chaîne de certificats. Peu importe combien de certificats il existe dans la chaîne, je peux valider chaque signature tout le chemin jusqu'à la racine. Quand j'arrive à la racine, je peux vérifier si ce certificat racine est celui que j'ai explicitement la confiance. Si oui, alors je peut faire confiance à l'ensemble de la chaîne.

Conféré Confiance

Authentification TLS utilise un système de conféré confiance. Si je veux embaucher un mécanicien automobile, je ne peut pas faire confiance à aucun hasard mécanicien que je trouve. Mais peut-être que mon ami se porte garant pour un mécanicien. Depuis que j'ai confiance en mon ami, alors je peux avoir confiance que mécanicien.

Lorsque vous achetez un ordinateur ou de télécharger un navigateur, il est livré avec quelques centaines de certificats racine explicitement les fiducies.[4] Les entreprises qui possèdent et exploitent ces certificats peuvent lui donner confiance à d'autres organismes par la signature de leurs certificats.

C'est loin d'être un système parfait. Quelques fois CA peut délivrer un certificat à tort. Dans ces cas, le certificat doit être révoqué. La révocation est délicate, car le certificat émis sera toujours chiffrée de manière correcte; un out-of-band protocole est nécessaire pour savoir qui, auparavant, des certificats valides ont été révoqué. Dans la pratique, certains de ces protocoles ne sont pas très sûres, et de nombreux navigateurs ne pas vérifier de toute façon.

Parfois, toute une CA est compromise. Par exemple, si vous étiez à percer dans Verisign et de voler leur racine de la clé de signature, puis vous pourrait usurper tout certificat dans le monde. Notez que ce n'est pas seulement affecter Verisign clients: même si mon certificat est signé par Thawte (un concurrent de Verisign), qui n'a pas d'importance. Mon certificat peut encore être établi à l'aide de la clé de signature de compromis de Verisign.

Ce n'est pas seulement théorique. Il est arrivé à l'état sauvage. DigiNotar a été célèbre piraté et par la suite fait faillite. Comodo a également été piraté, mais inexplicablement, ils restent dans les affaires à ce jour.

Même lorsque les Ac ne sont pas directement compromise, il y a d'autres menaces dans ce système. Par exemple, un gouvernement d'utiliser la coercition légale pour obliger une autorité de certification pour signer un faux certificat. Votre employeur peut installer leur propre certificat d'autorité de certification sur votre ordinateurs des employés. Dans ces divers cas, de la circulation que vous vous attendez à être "sécurisé" est en fait complètement visibles et modifiables à l'organisation qui contrôle ce certificat.

Certains remplacements ont été proposées, notamment La Convergence, TACK, et DANE.

Notes de fin de document

[1] certificat TLS données sont formatées selon le X. 509 standard. X. 509 est basé sur L'ASN.1 ("Abstract syntax Notation #1"), ce qui signifie qu'il est pas un format de données binaire. Par conséquent, X. 509 doit être codé dans un format binaire. DER et PEM la plupart des encodages, que je sache.

[2] Dans la pratique, le protocole fait des commutateurs à un chiffrement symétrique, mais c'est un détail qui n'est pas pertinent à votre question.

[3] Présumable, la CA fait valide qui vous êtes avant de signer votre certificat. S'ils n'avaient pas le faire, alors je pourrais juste créer un certificat pour google.com et de demander à une autorité de certification pour signer. Avec qui certificiate, je pourrais man-in-the-middle " aucune connexion "sécurisée" pour google.com. Par conséquent, l'étape de validation est un facteur très important dans le fonctionnement d'un CA. Malheureusement, c'est pas très clair comment rigoureux de ce processus de validation est à des centaines de CAs à travers le monde.

[4] Voir Mozilla liste d'autorités de certification approuvées.

J'ai écrit un petit billet de blog qui traite du processus brièvement. N'hésitez pas à jeter un oeil.

SSL Handshake

Un petit extrait de la même est comme suit:

"Client fait une requête au serveur via le protocole HTTPS. Le serveur envoie une copie de son certificat SSL + clé publique. Après vérification de l'identité du serveur avec local de son autorité de certification de confiance magasin, le client génère un secret de la clé de session, le chiffre à l'aide de la clé publique du serveur et l'envoie. Serveur déchiffre le secret de la clé de session à l'aide de sa clé privée et envoie un accusé de réception au client. Canal sécurisé établi."