Comment fonctionne vraiment SSL?

143

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?

Vicky
la source
24
Je pense que c'est une question raisonnable - comprendre comment fonctionne SSL est l'étape 1, l'implémenter correctement est l'étape 2 à l'infini.
synthesizerpatel
5
@StingyJack Ne soyez pas un nazi politique ici. Les gens viennent chercher de l'aide. Ne leur refusez pas toute assistance car vous trouvez que la question ne correspond pas parfaitement aux règles.
Koray Tugay
1
@KorayTugay - personne ne refuse l'assistance. Cela appartient à Security ou Sysadmin où il est mieux ciblé, mais OP bénéficierait généralement de ce forum en ajoutant un peu de contexte de programmation au lieu de publier une question informatique générale. Combien de personnes obtiennent des questions fermées lorsqu'elles ne sont pas liées à un problème de programmation spécifique? Probablement trop, d'où mon coup de pouce OP pour faire cette association.
StingyJack

Réponses:

144

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:

  1. Cryptez vos données de couche d'application. (Dans votre cas, le protocole de la couche application est HTTP.)
  2. Authentifiez le serveur auprès du client.
  3. 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 .

Mark E. Haase
la source
Qu'est-ce qu'une clé privée?
Koray Tugay
vous avez oublié de mentionner que la clé publique fait partie du fichier de certificat envoyé au site Web pour déchiffrer les données chiffrées par votre serveur en premier lieu.
mamdouh alramadan
Merci @mamdouhalramadan. J'ai édité pour le mentionner.
Mark E. Haase
2
@mamdouhalramadan "la clé publique est ... envoyée au site Web pour décrypter les données". Comment la clé publique peut-elle être utilisée pour décrypter les données?
Teddy
@ateddy Vous avez raison. Ça ne peut pas. La clé publique n'est utilisée que pour l'authentification. L'affirmation ici que les paires de clés sont également utilisées pour le cryptage et le décryptage est incorrecte. Une clé de session négociée en toute sécurité est utilisée pour cela.
Marquis of Lorne
53

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?

  1. Le navigateur essaie de se connecter à https://payment.com .
  2. Le serveur de payment.com envoie un certificat au navigateur. Ce certificat comprend la clé publique du serveur de payment.com et certaines preuves que cette clé publique appartient réellement à payment.com.
  3. Le navigateur vérifie le certificat pour confirmer qu'il possède la clé publique appropriée pour payment.com.
  4. Le navigateur choisit une nouvelle clé symétrique K aléatoire à utiliser pour sa connexion au serveur de payment.com. Il crypte K sous la clé publique de payment.com.
  5. payment.com décrypte K à l'aide de sa clé privée. Désormais, le navigateur et le serveur de paiement connaissent K, mais personne d'autre ne le sait.
  6. Chaque fois que le navigateur veut envoyer quelque chose à payment.com, il le crypte sous K; le serveur de payment.com le déchiffre dès sa réception. Chaque fois que le serveur de payment.com souhaite envoyer quelque chose à votre navigateur, il le crypte sous K.

Ce flux peut être représenté par le schéma suivant: entrez la description de l'image ici

sanjay_kv
la source
1
La partie sur le chiffrement et l'envoi de la clé de session et sa décryptage sur le serveur est complète et sans fondement. La clé de session n'est jamais transmise du tout: elle est établie via un algorithme de negoatiaon de clé sécurisée. Veuillez vérifier vos faits avant de publier des bêtises comme celle-ci. RFC 2246.
Marquis of Lorne
Pourquoi le navigateur n'utilise-t-il pas la clé publique du serveur pour crypter les données lorsqu'il les publie sur le serveur, au lieu de créer une nouvelle clé symétrique K aléatoire à l'étape 4?
KevinBui
1
@KevinBui Parce que l'envoi de la réponse depuis le serveur nécessiterait que le client ait une paire de clés, et parce que le cryptage asymétrique est très lent.
Marquis of Lorne
3

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. "

Abhishek Jain
la source
«Après avoir vérifié l'identité du serveur avec son magasin local CA de confiance» - ce n'est pas strictement vrai. Je peux utiliser un certificat auto-signé et HTTPS fonctionnerait - je peux obtenir une connexion HTTPS sécurisée à un serveur . Le certificat de confiance entre uniquement lorsque je veux m'assurer que je parle au bon serveur.
Teddy
La partie sur le chiffrement et l'envoi de la clé de session et sa décryptage sur le serveur est complète et sans fondement. La clé de session n'est jamais transmise du tout: elle est établie via un algorithme de negoatiaon de clé sécurisée. Veuillez vérifier vos faits avant de publier des bêtises comme celle-ci. RFC 2246.
Marquis of Lorne
@Teddy Ce n'est pas correct. La vérification de la confiance des certificats est une partie obligatoire de SSL. Il peut être contourné mais il est normalement en vigueur: les certificats auto-signés ne fonctionnent pas sans mesures spéciales d'un type ou d'un autre.
Marquis of Lorne
2

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:

Ne considérez pas les CERTIFICATS et SSL comme un seul sujet. Traitez-les comme 2 sujets différents, puis essayez de voir avec qui ils travaillent ensemble. Cela vous aidera à répondre à la question.

É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.

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 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

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?

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

  • Afin de comprendre les certificats, vous devrez comprendre ce que sont les certificats et également lire sur la gestion des certificats. C’est important.
  • Une fois que cela est compris, procédez à la négociation TLS / SSL. Vous pouvez consulter les 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.

Kaushal Kumar Panday
la source