Comment les certificats SSL sont-ils vérifiés?
Quelles sont les étapes à suivre pour vérifier en toute sécurité un certificat SSL? Ma compréhension (très limitée) est que lorsque vous visitez un site https, le serveur envoie un certificat au client (le navigateur) et le navigateur récupère les informations sur l'émetteur du certificat à partir de ce certificat, puis les utilise pour contacter l'émetteur et les compare. certificats de validité.
- Comment cela se fait-il exactement?
- Qu'en est-il du processus qui le rend immunisé contre les attaques de type homme du milieu?
- Qu'est-ce qui empêche une personne aléatoire de configurer son propre service de vérification afin de l'utiliser dans des attaques de type "man-in-the-middle", de sorte que tout "semble" sécurisé?
Voici une explication très simplifiée:
Votre navigateur Web télécharge le certificat du serveur Web, qui contient la clé publique du serveur Web. Ce certificat est signé avec la clé privée d'une autorité de certification de confiance.
Votre navigateur Web est installé avec les clés publiques de toutes les principales autorités de certification. Il utilise cette clé publique pour vérifier que le certificat du serveur Web a bien été signé par l'autorité de certification approuvée.
Le certificat contient le nom de domaine et/ou l'adresse IP du serveur Web. Votre navigateur Web confirme avec l'autorité de certification que l'adresse indiquée dans le certificat est celle avec laquelle il dispose d'une connexion ouverte.
Votre navigateur Web génère une clé symétrique partagée qui sera utilisée pour chiffrer le trafic HTTP sur cette connexion. c'est beaucoup plus efficace que d'utiliser le cryptage à clé publique/privée pour tout. Votre navigateur chiffre la clé symétrique avec la clé publique du serveur Web, puis la renvoie, garantissant ainsi que seul le serveur Web peut la déchiffrer, car seul le serveur Web dispose de sa clé privée.
Notez que l’autorité de certification est essentielle pour empêcher les attaques de type intermédiaire. Cependant, même un certificat non signé empêchera quelqu'un d'écouter passivement votre trafic crypté, car il ne dispose d'aucun moyen pour accéder à votre clé symétrique partagée.
Il convient de noter qu’en plus de l’achat d’un certificat (comme mentionné ci-dessus), vous pouvez également créer le vôtre gratuitement. c'est ce qu'on appelle un "certificat auto-signé". La différence entre un certificat auto-signé et un certificat acheté est simple: le certificat acheté a été signé par une autorité de certification connue de votre navigateur. En d’autres termes, votre navigateur peut facilement valider l’authenticité d’un certificat acheté.
Malheureusement, cela a conduit à une idée fausse commune selon laquelle les certificats auto-signés sont intrinsèquement moins sécurisés que ceux vendus par des autorités de certification 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 distribuez de manière sécurisée un certificat auto-signé (ou un certificat CA, comme suggéré par bobince) et l'installez dans les navigateurs qui utiliseront votre site , c'est simplement aussi sûr que celui qui est acheté et n'est pas vulnérable aux attaques de l'homme du milieu et à la falsification de certificats. Évidemment, cela signifie que cela n'est possible que si quelques personnes seulement ont besoin d'un accès sécurisé à votre site (applications internes, blogs personnels, etc.).
Dans le but de sensibiliser davantage et d'encourager les petits bloggeurs comme moi à se protéger, j'ai rédigé un didacticiel débutant qui explique plus en détail les concepts à la base des certificats et explique comment créer et utiliser en toute sécurité un certificat auto-signé. (complet avec des exemples de code et des screenshots).
Vous avez dit que
le navigateur obtient les informations sur l'émetteur du certificat à partir de ce certificat, puis les utilise pour contacter l'émetteur et compare d'une manière ou d'une autre les certificats pour en vérifier la validité.
Le client n'a pas à vérifier auprès de l'émetteur parce que deux choses:
- tous les navigateurs ont une liste préinstallée de toutes les clés publiques des principales autorités de certification
- le certificat est signé et cette signature est en soi une preuve suffisante de sa validité, car le client peut s'assurer, de son propre chef et sans contacter le serveur de l'émetteur, que ce certificat est authentique. C'est la beauté du cryptage asymétrique.
Notez que 2. ne peut pas être fait sans 1.
Ceci est mieux expliqué dans ce grand diagramme je l'ai fait il y a quelque temps
(passez à "qu'est-ce qu'une signature?" en bas)
si vous êtes plus techniquement intéressé, ce site est probablement ce que vous voulez: http://www.zytrax.com/tech/survival/ssl.html
avertissement: le terrier du lapin va en profondeur :).
Le client dispose d'un magasin prédéfini de clés publiques des autorités de certification SSL. Pour que le serveur soit fiable, il doit exister une chaîne de confiance à partir du certificat pour le serveur, par le biais d'autorités intermédiaires, jusqu'à l'un des certificats dits "racine".
Vous pouvez examiner et/ou modifier la liste des autorités de confiance. Vous faites souvent cela pour ajouter un certificat pour une autorité locale en laquelle vous savez que vous avez confiance - par exemple, l'entreprise pour laquelle vous travaillez, l'école que vous fréquentez ou non.
La liste préconfigurée peut varier en fonction du client que vous utilisez. Les grands fournisseurs de certificats SSL s'assurent que leurs certificats racine figurent dans tous les principaux navigateurs ($$$).
Les attaques de type singe au milieu sont "impossibles" à moins que l'attaquant ne dispose de la clé privée d'un certificat racine approuvé. Étant donné que les certificats correspondants sont largement déployés, l'exposition d'une telle clé privée aurait de graves conséquences pour la sécurité du commerce électronique en général. De ce fait, ces clés privées sont très, très étroitement surveillées.