web-dev-qa-db-fra.com

Cadre de certificat SSL 101: Comment le navigateur vérifie-t-il réellement la validité d'un certificat de serveur donné?

(Désolé, je sais que c'est une question noob complète et au risque de publier un sujet quelque peu en double. J'ai une compréhension de base de la clé publique/privée, du hachage, de la signature numérique ... J'ai recherche sur le forum en ligne et pile depuis quelques jours mais ne semble pas trouver de réponse satisfaisante.)

Exemple: Je surfe sur le wifi ouvert et je navigue pour la 1ère fois. Le serveur renvoie son certificat SSL. Mon navigateur fait son travail et vérifie que le certificat est signé par une autorité de certification à laquelle il fait confiance et tout va bien. Je clique sur le site Web. MAIS!

Question: Quelqu'un peut-il m'expliquer de manière simple comment mon navigateur vérifie réellement que le certificat de serveur est légitime? Ouais ok donc sur le certificat lui-même, il dit qu'il est délivré par, dites "Verisign" mais quelle est la magie cryptographique réelle qui se passe derrière la scène pour valider qu'il ne s'agit pas d'un faux certificat? J'ai entendu des gens expliquer "Les certificats SSL sont vérifiés à l'aide de la clé publique de l'autorité de certification signataire", mais cela n'a pas de sens pour moi. Je pensais que la clé publique est de crypter des données, pas de décrypter des données.

Tellement confus ... apprécie si quelqu'un pouvait m'éclairer. Merci d'avance!

75
SecurityNoob

Vous avez raison de dire que SSL utilise une paire de clés asymétriques. Une clé publique et une clé privée sont générées, également appelées infrastructure à clé publique (PKI). La clé publique est ce qui est distribué dans le monde et est utilisé pour crypter les données. Cependant, seule la clé privée peut réellement déchiffrer les données. Voici un exemple:

Disons que nous allons tous les deux sur walmart.com et achetons des trucs. Chacun de nous obtient une copie de la clé publique de Walmart pour signer notre transaction. Une fois la transaction signée par la clé publique de Walmart, seule la clé privée de Walmart peut déchiffrer la transaction. Si j'utilise ma copie de la clé publique de Walmart, elle ne décryptera pas votre transaction. Walmart doit garder sa clé privée très privée et sécurisée, sinon toute personne qui l'obtient peut décrypter les transactions vers Walmart. C'est pourquoi la violation DigiNotar était si importante

Maintenant que vous avez l'idée des paires de clés privées et publiques, il est important de savoir qui délivre réellement le certificat et pourquoi les certificats sont approuvés. Je simplifie à l'excès, mais il existe des autorités de certification racine spécifiques (CA) telles que Verisign qui signent les certificats, mais signent également pour les CA intermédiaires. Cela suit ce qu'on appelle la chaîne de confiance, qui est une chaîne de systèmes qui se font mutuellement confiance. Voir l'image liée ci-dessous pour avoir une meilleure idée (notez que l'autorité de certification racine est en bas).

Simple Chain of Trust

Les organisations achètent souvent des certificats génériques ou sont elles-mêmes enregistrées en tant qu'autorité de certification intermédiaire autorisée à signer pour leur domaine uniquement. Cela empêche Google de signer des certificats pour Microsoft.

En raison de cette chaîne de confiance, un certificat peut être vérifié jusqu'à l'autorité de certification racine. Pour le montrer, DigiCert (et bien d'autres) dispose d'outils pour vérifier cette confiance. L'outil de DigiCert est lié ici . J'ai fait une validation sur gmail.com et lorsque vous faites défiler vers le bas, cela montre ceci:

Certificate of Trust for Gmail

Cela montre que le certificat pour gmail.com est émis par Google Internet Authority G2, qui à son tour a émis un certificat de GeoTrust Global, qui à son tour a émis un certificat d'Equifax.

Maintenant, lorsque vous allez sur gmail.com, votre navigateur ne se contente pas de récupérer un hash et continue son chemin. Non, il obtient une multitude de détails avec le certificat:

Google Public Cert Details

Ces détails sont ce que votre navigateur utilise pour aider à identifier la validité du certificat. Par exemple, si la date d'expiration est passée, votre navigateur générera une erreur de certificat. Si tous les détails de base du certificat sont extraits, il vérifiera tout le chemin jusqu'à l'autorité de certification racine, que le certificat est valide.

Maintenant que vous avez une meilleure idée des détails du certificat, cette image développée similaire à la première ci-dessus aura, espérons-le, plus de sens:

Certificate Chain of Trust Expanded

C'est pourquoi votre navigateur peut vérifier un certificat par rapport au suivant, jusqu'à l'autorité de certification racine, à laquelle votre navigateur fait confiance de manière inhérente.

J'espère que cela vous aidera à mieux comprendre!

75
PTW-105

Pour clarifier un point de la question non abordée dans l'excellente réponse par @ PTW-105 (et posée dans le commentaire par @ JVE999):

Je pensais que la clé publique est de crypter des données, pas de décrypter des données ...

Les clés fonctionnent dans les deux sens - ce qui est chiffré avec la clé publique ne peut être déchiffré qu'avec le privé et vice versa . Nous décidons simplement que l'un est privé et l'autre public, il n'y a pas de différence conceptuelle.

Donc, si je crypte les données à vous envoyer, j'utilise votre clé publique pour la crypter et vous seul pouvez la décrypter avec votre clé privée.

Cependant, si je veux signer quelque chose, pour prouver que cela vient de moi, alors je génère un hachage du message et je crypte ce hachage avec mon clé privée . Ensuite, tout le monde peut le décrypter avec ma clé publique et le comparer au hachage de message réel, mais ils savent que seul j'aurais pu le chiffrer, car seul j'ai ma clé privée. Ils savent donc que le hachage du message n'a pas changé depuis que je l'ai signé, et donc qu'il vient de moi.

Selon les commentaires, ce qui précède n'est pas tout à fait vrai. Voir le lien du commentaire de @ dave_thompson_085. Cependant, ce n'est pas un tutoriel "comment signer correctement", clarifiant simplement les rôles des clés privées et publiques dans la signature des vers de chiffrement. Le point fondamental à cet égard est le suivant:

  • Pour chiffrer les données, la partie externe utilise une clé publique et seul le détenteur de la clé privée peut la déchiffrer.
  • Pour signer, le détenteur de la clé privée utilise une fonction de hachage et sa clé privée (plus un remplissage approprié, etc.). La partie externe peut ensuite vérifier la signature à l'aide de la clé publique. Cela garantit que le message provient du détenteur de la clé privée (en supposant que personne d'autre n'a accès à la clé privée).

La signature peut parfois (selon l'implémentation) être effectuée avec la même paire de clés que le cryptage, simplement utilisée dans l'autre sens, ou elle peut utiliser une paire de clés distincte (voir n autre lien , également de @ dave_thompson_085's commentaire)

2
Adam

Si un site Web possède un certificat valide, cela signifie qu'une autorité de certification a pris des mesures pour vérifier que l'adresse Web appartient réellement à cette organisation. Lorsque vous tapez une URL ou suivez un lien vers un site Web sécurisé, votre navigateur vérifie le certificat pour les caractéristiques suivantes: l'adresse du site Web correspond à l'adresse sur le certificat, le certificat est signé par une autorité de certification (CA) que le navigateur reconnaît comme une autorité "de confiance"

Les protocoles TLS et SSL utilisent tous deux ce qu'on appelle un système d'infrastructure à clé publique (PKI) "asymétrique". Un système asymétrique utilise deux "clés" pour crypter les communications, une clé "publique" et une clé "privée". Tout ce qui est chiffré avec la clé publique ne peut être déchiffré que par la clé privée et vice-versa. Lorsque vous accédez à un site, un site Web présente sa clé publique que votre navigateur valide et utilise pour crypter les données envoyées (entre votre navigateur et son serveur) et seul le serveur/site possède la clé privée qui est capable de décrypter les données.

Quelques informations sur les clés: le cryptage asymétrique (ou cryptographie à clé publique) utilise une clé distincte pour le cryptage et le décryptage. Tout le monde peut utiliser la clé de cryptage (clé publique) pour crypter un message. Cependant, les clés de déchiffrement (clés privées) sont secrètes. De cette façon, seul le destinataire prévu peut déchiffrer le message. L'algorithme de chiffrement asymétrique le plus courant est RSA; cependant, nous discuterons des algorithmes plus loin dans cet article.

crédit complet à ces sites:

https://www.us-cert.gov/ncas/tips/ST05-01

https://www.digicert.com/ssl-cryptography.htm

0
grepit