Comment fonctionne SSL?
Où le certificat est-il installé sur le client (ou navigateur?) Et le serveur (ou serveur Web?)?
Comment le processus de confiance / cryptage / authentification démarre-t-il lorsque vous entrez l'URL dans le navigateur et récupérez 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?
ssl
ssl-certificate
Vicky
la source
la source
Réponses:
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:
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:
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é .
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 .
la source
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-ce nécessaire?
HTTPS crypte les données transmises du navigateur au serveur sur 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?
Ce flux peut être représenté par le schéma suivant:
la source
J'ai écrit un petit article de blog qui traite brièvement du processus. N'hésitez pas à jeter un coup d'œil.
Prise de contact SSL
Un petit extrait du même est le suivant:
"Le client envoie 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 local de l'autorité de certification de confiance, le client génère une clé de session secrète, la crypte à l'aide du 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. "
la source
Mehaase l'a déjà expliqué en détail. J'ajouterai mes 2 cents à cette série. J'ai de nombreux articles de blog qui tournent autour de la négociation SSL et des certificats. Bien que la plupart de cela tourne autour du serveur Web IIS, le message est toujours pertinent pour la négociation SSL / TLS en général. En voici quelques-uns pour votre référence:
Établir 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 possède une liste des autorités de certification racine et intermédiaires qu'il gère. Ceux-ci sont mis à jour périodiquement. Pendant la négociation SSL, ceci est utilisé comme référence pour établir la confiance. Par exemple, lors de la négociation 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 des autorités de certification. Lorsqu'il ne peut pas faire cela, 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 AIApour cela.) Le client effectue é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.
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 séparés.
La négociation SSL utilise à la fois la cryptographie à clé symétrique et publique. L'authentification du serveur se produit par défaut. L'authentification du client est facultative et dépend si le point de terminaison du serveur est configuré pour authentifier le client ou non. Reportez-vous à mon article de blog car je l'ai expliqué en détail.
Enfin pour cette question
Certificates est 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'un communicateur. HTTPS = HTTP + SSL est un protocole qui définit les directives sur la façon dont 2 parties doivent communiquer entre elles.
PLUS D'INFORMATION
Si l'activité ci-dessus est effectuée, vous aurez une bonne compréhension des certificats et SSL.
la source