Détails de la vérification du certificat TLS
Je comprends les bases de la cryptographie, mais je suis incertain des trois étapes suivantes:
Étape 1: Comment calculer un certificat TLS
Corrigez-moi si je me trompe: l'autorité de certification calcule une valeur de hachage sur les informations de certificat pertinentes (y compris la clé publique du certificat aplicant), il signe une valeur de hachage à l'aide de la clé privée de l'autorité. La sortie de ce processus est un fichier de certificat unique pouvant être déployé sur des serveurs qui ont accès à la clé privée correspondante.
Étape 2: Comment vérifier que le serveur possède la clé privée correspondant au certificat TLS?
Le client obtient le certificat du serveur pendant la poignée de main TLS. Mais le certificat à lui seul n'est pas suffisant pour vérifier l'authenticité des données. (Étant donné que quelqu'un pourrait envoyer une copie d'un certificat sans posséder la clé privée), je pense donc qu'il doit y avoir des informations aléatoires supplémentaires transmises, qui doivent être signées à l'aide de la clé privée correspondante (peut-être aussi en calculant un hachage)?
Le client décrypte-t-il ces informations aléatoires avec la clé publique du certificat? Comment se passe ce chèque?
Étape 3: Comment vérifier que le certificat est signé par une autorité de confiance?
Je pense que cela fonctionne principalement avec des tables de navigateur préinstallées contenant les clés publiques de l'autorité de confiance (entre autres informations).
Les clés publiques de l'autorité de certification sont-elles utilisées pour déchiffrer une valeur de hachage et vérifier si elle correspond à une valeur de hachage automatiquement calculée sur l'ensemble du certificat?
Une réponse à la question 1:
Oui, à l'exception de la racine de CA est hors ligne dans un HSM dans une voûte, non disponible pour être volée électroniquement. La racine a été utilisée pour signer une poignée de certificats intermédiaires (sauvegères et certificats de répondants OCSP et autres objets) qui résident dans HSMS directement connectés aux ordinateurs pouvant être atteints électroniquement.
Pour émettre un certificat, le CA "Backend":
- reçoit la CSR
- utilise une méthode de validation (protocole ACME, en cliquant sur Human "OK" sur le site Web de l'administration, etc.)
- enregistre toutes les décisions et informations utilisées pour prendre la décision de vérifier par une audit ultérieure
- génère les données de certificat (X.509 V3) codées dans X.690 der, à l'aide d'un modèle et de nouveau numéro de série/source de hasard.
- peut-être obtenir des scts de transparence de certificat.
- demande au HSM de signer le blob (ou hachage du blob).
- ajoute la signature au certificat et l'envoie au client de stockage.
Une réponse à la question 2:
En échange de clé RSA, le client génère une séquence aléatoire d'octets et effectue un cryptage RSA à l'aide de la clé publique à partir du certificat du serveur. Ensuite, le client envoie le CIPHERText résultant au serveur et s'attend à ce que le serveur le déchiffre (à l'aide de la clé privée correspondant à la clé publique du certificat) et utilisez la valeur aléatoire dans une KDF, ainsi que d'autres valeurs pour générer des clés symétriques et Envoyez un message fini crypté avec les touches symétriques résultantes. Le client vérifie le message fini. Le serveur ne peut réussir que pour générer les clés symétriques attendues par le message crypté RSA de décryptage. https://tools.ietf.org/html/rfc5246#appendix-f.1.1.2
Dans l'échange de clé DHE/ECDHE avec PFS, le serveur signe sa clé éphémère à l'aide de la clé privée correspondant à la clé publique du certificat et l'envoie dans ServerKeyExchange. Le client vérifie la signature à l'aide de la clé publique du certificat. https://tools.ietf.org/html/rfc5246#appendix-f.1.1.
Une réponse à la question 3: Le navigateur contient une liste de racines de confiance (Mozilla Firefox le fait) ou utilise une liste de racines de confiance fournies par le système d'exploitation (Google Chrome utilise le magasin de racines du système d'exploitation) . Le magasin racine contient des certificats auto-signés et des métadonnées à leur sujet qui pourraient contraindre ce qu'elles peuvent être utilisées. Les navigateurs contiennent également du code qui ajoute des contrôles supplémentaires, comme Chrome nécessitant la transparence du certificat de Symantec- possédée de CAS et les dates de coupure qui permettent d'utiliser des certificats SHA1.
La manière dont un serveur de feuilles/un certificat de domaine est vérifiée à l'aide du magasin racine consiste en construisant une chaîne de certificats intermédiaires, une signature de l'autre, d'une racine de confiance à la feuille. La racine signe un intermédiaire et l'intermédiaire signe la feuille. Il peut y avoir plus d'un intermédiaire dans une chaîne. Les intermédiaires sont envoyés par le serveur avec la feuille. https://fr.wikipedia.org/wiki/certification_path_validation_algorithm
Différents ordinateurs ont différents magasins racines et en utilisant la signature croisée, de nombreux chemins différents peuvent être construits. Actuellement, les navigateurs tentent de construire des chemins SHA256 uniquement, si possible, échouez et produisent parfois une erreur en disant qu'un chemin SHA1 a été construit, la connexion peut être insécuritée.
Ne confondez pas les signatures numériques avec le cryptage: https://security.stackexchange.com/a/87373/708