Comment les certificates SSL sont-ils vérifiés?

Quelle est la série d’étapes nécessaires pour vérifier en toute sécurité un certificate SSL? Ma compréhension (très limitée) est que lorsque vous visitez un site https, le serveur envoie un certificate au client (le navigateur) et le navigateur obtient les informations d’émetteur du certificate à partir de ce certificate, puis les utilise pour comparer l’émetteur. certificates de validité.

  • Comment cela se fait-il exactement?
  • Qu’en est-il du processus qui le rend insensible aux attaques de l’homme du milieu?
  • Qu’est-ce qui empêche une personne au hasard de mettre en place son propre service de vérification à utiliser dans les attaques de type intermédiaire, de sorte que tout semble “sécurisé”?

Voici une explication très simplifiée:

  1. Votre navigateur Web télécharge le certificate du serveur Web, qui contient la clé publique du serveur Web. Ce certificate est signé avec la clé privée d’une autorité de certificateion approuvée.

  2. Votre navigateur Web est installé avec les clés publiques de toutes les principales autorités de certificateion. Il utilise cette clé publique pour vérifier que le certificate du serveur Web a bien été signé par l’autorité de certificateion approuvée.

  3. Le certificate contient le nom de domaine et / ou l’adresse IP du serveur Web. Votre navigateur Web confirme avec l’autorité de certificateion que l’adresse indiquée dans le certificate est celle à laquelle il a une connexion ouverte.

  4. Votre navigateur Web génère une clé symésortingque partagée qui sera utilisée pour chiffrer le trafic HTTP sur cette connexion. c’est beaucoup plus efficace que d’utiliser le chiffrement par clé publique / privée pour tout. Votre navigateur crypte la clé symésortingque avec la clé publique du serveur Web, puis la renvoie, garantissant ainsi que seul le serveur Web peut le décrypter, puisque seul le serveur Web possède sa clé privée.

Notez que l’autorité de certificateion (CA) est essentielle pour empêcher les attaques de type intermédiaire. Cependant, même un certificate non signé empêchera quelqu’un d’écouter passivement votre trafic chiffré, car ils n’ont aucun moyen d’accéder à votre clé symésortingque partagée.

Il convient de noter qu’en plus de l’achat d’un certificate (comme mentionné ci-dessus), vous pouvez également créer votre propre certificate gratuitement; c’est ce qu’on appelle un “certificate auto-signé”. La différence entre un certificate auto-signé et un certificate acheté est simple: celui acheté a été signé par une autorité de certificateion que votre navigateur connaît déjà. En d’autres termes, votre navigateur peut facilement valider l’authenticité d’un certificate acheté.

Malheureusement, cela a conduit à une idée fausse commune selon laquelle les certificates auto-signés sont insortingnsèquement moins sécurisés que ceux vendus par les autorités de certificateion commerciales telles que GoDaddy et Verisign, et que vous devez respecter les avertissements / exceptions du navigateur si vous les utilisez; c’est incorrect

Si vous dissortingbuez en toute sécurité un certificate auto-signé (ou un certificate CA, comme suggéré par Bobince) et que vous l’installez dans les navigateurs qui utiliseront votre site , il est tout aussi sécurisé que celui acheté et n’est pas vulnérable à l’homme intermédiaire. attaques et falsification de cert. Évidemment, cela signifie que ce n’est possible que si quelques personnes seulement ont besoin d’un access sécurisé à votre site (par exemple, des applications internes, des blogs personnels, etc.).

Dans le but de sensibiliser et d’encourager d’autres blogueurs de petite taille comme moi à se protéger, j’ai rédigé un didacticiel de base qui explique plus en détail les concepts sous-jacents aux certificates et comment créer et utiliser un certificate auto-signé en toute sécurité. (complet avec des exemples de code et des captures d’écran). Voici un lien au cas où cela serait utile à quiconque à l’avenir: http://www.clintharris.net/2009/self-signed-certificatees/ .

Vous avez dit que

le navigateur obtient les informations sur l’émetteur du certificate à partir de ce certificate, puis les utilise pour contacter l’émetteur et compare d’une manière ou d’une autre les certificates pour vérifier leur validité.

Le client n’a pas à vérifier avec l’émetteur parce que deux choses:

  1. tous les navigateurs ont une liste préinstallée de toutes les principales clés publiques de l’autorité de certificateion
  2. le certificate est signé et cette signature elle-même est une preuve suffisante que le certificate est valide car le client peut s’assurer, par ses propres moyens et sans contacter le serveur de l’émetteur, que ce certificate est authentique. C’est la beauté du cryptage asymésortingque.

Notez que 2. ne peut pas être fait sans 1.

Ceci est mieux expliqué dans ce grand diagramme que j’ai fait il y a quelque temps

(passez à “Qu’est-ce qu’une signature?” en bas)

goutte

Le client dispose d’un magasin pré-ensemencé de clés publiques des autorités de certificateion SSL. Il doit exister une chaîne de confiance entre le certificate du serveur et les autorités intermédiaires jusqu’à un des certificates dits “racine” pour que le serveur soit approuvé.

Vous pouvez examiner et / ou modifier la liste des autorités de confiance. Vous faites souvent cela pour append un certificate pour une autorité locale en laquelle vous avez confiance – comme la société pour laquelle vous travaillez ou l’école que vous fréquentez ou non.

La liste pré-ensemencée peut varier en fonction du client que vous utilisez. Les grands fournisseurs de certificates SSL s’assurent que leurs certificates racine se trouvent dans tous les principaux navigateurs ($$$).

Les attaques Monkey-in-the-Middle sont “impossibles” à moins que l’attaquant ait la clé privée d’un certificate racine de confiance. Les certificates correspondants étant largement déployés, l’exposition d’une telle clé privée aurait de graves conséquences sur la sécurité du commerce électronique en général. À cause de cela, ces clés privées sont très, très étroitement gardées.

Si vous êtes plus technique, ce site est probablement ce que vous voulez: http://www.zytrax.com/tech/survival/ssl.html

avertissement: le trou de lapin va en profondeur :).