Bonjour à tous, je suis Lao Tian et je suis spécialisé dans le partage d'informations utiles avec vous. De plus, amis qui ont besoin de matériel d'entretien, n'oubliez pas de répondre dans les coulisses面试
Tout le monde sait que HTTPS est plus sécurisé que HTTP, et a également entendu dire que les concepts liés au HTTPS Le protocole inclut SSL, le cryptage non symétrique, le certificat CA, etc.
Mais vous ne pourrez peut-être pas répondre aux trois questions suivantes sur la torture de l'âme :
Cet article approfondira et expliquera le principe de la sécurité du HTTPS.
Vous avez peut-être entendu dire que la raison pour laquelle le protocole HTTPS est sécurisé est parce que le protocole HTTPS crypte les données transmises et que le processus de cryptage utilise un cryptage asymétrique.
Mais en fait, HTTPS utilise le cryptage symétrique pour crypter la transmission du contenu, et le cryptage asymétrique ne fonctionne que dans la phase de vérification du certificat.
Le processus global du HTTPS est divisé en étapes de vérification du certificat et de transmission des données. Le processus d'interaction spécifique est le suivant :
Étape de vérification du certificat :
Étape de transmission des données :
Tout d'abord, l'efficacité du cryptage et du déchiffrement du cryptage asymétrique est très faible, et dans les scénarios d'application HTTP, il y a généralement de nombreuses interactions entre bout en bout, donc l'efficacité du cryptage asymétrique est inacceptable.
De plus, dans le scénario HTTPS, seul le serveur enregistre la clé privée, et une paire de clés publiques et privées ne peut réaliser qu'un cryptage et un déchiffrement unidirectionnels. Par conséquent, le cryptage de la transmission de contenu dans HTTPS adopte un cryptage symétrique au lieu d'un cryptage asymétrique. cryptage.
Le protocole HTTP est considéré comme dangereux car le processus de transmission peut facilement être accroché par les auditeurs pour surveiller et forger des serveurs, tandis que le protocole HTTPS résout principalement le problème de sécurité de la transmission réseau.
Tout d'abord, nous supposons qu'il n'y a pas d'autorité de certification et que n'importe qui peut créer un certificat. Le risque de sécurité que cela entraîne est le problème classique de « l'attaque de l'homme du milieu ».
Le processus spécifique de « l'attaque de l'homme du milieu » est le suivant :
Le principe du processus est le suivant :
En raison de l'absence de vérification du certificat, bien que le client initie une requête HTTPS, le client n'a aucune idée que son réseau a été intercepté et que tout le contenu de la transmission a été volé par l'intermédiaire.
Comment le navigateur assure-t-il la légitimité du certificat CA ?
Le certificat contient les informations suivantes :
Tout d'abord, une organisation faisant autorité doit être certifiée. N'importe quelle organisation n'est pas qualifiée pour délivrer un certificat, sinon elle ne serait pas qualifiée d'organisation faisant autorité.
De plus, la crédibilité du certificat repose sur le système de confiance. L'organisation faisant autorité doit approuver le certificat qu'elle a émis. Tant qu'il s'agit d'un certificat généré par une organisation faisant autorité, nous le considérons comme légitime.
Ainsi, les organisations faisant autorité examineront les informations du demandeur. Les organisations faisant autorité à différents niveaux ont des exigences d'examen différentes, de sorte que les certificats sont également divisés en gratuits, bon marché et chers.
Lorsque le navigateur initie une requête HTTPS, le serveur renvoie le certificat SSL du site Web.
Le navigateur doit effectuer la vérification suivante sur le certificat :
** Déterminez si le certificat a été falsifié. ** Nécessite une vérification auprès du serveur CA.
** Déterminez si le certificat a été révoqué. **Obtenu via CRL (Certificate Revocation List) et OCSP (Online Certificate Status Protocol).
OCSP peut être utilisé à l'étape 3 pour réduire l'interaction avec le serveur CA et améliorer l'efficacité de la vérification.
Ce n'est que lorsque l'une des étapes ci-dessus est remplie que le navigateur considérera le certificat comme légitime.
**Voici une question à laquelle je réfléchis depuis longtemps mais la réponse est en fait très simple : **Le certificat étant public, si je veux lancer une attaque de type man-in-the-middle, je télécharge un certificat du site officiel comme certificat de mon serveur, alors le client Le client conviendra certainement que ce certificat est légitime. Comment éviter une telle utilisation frauduleuse du certificat ?
En fait, il s'agit de l'utilisation de clés publiques et privées dans une symétrie non chiffrée Bien que l'intermédiaire puisse obtenir le certificat, la clé privée ne peut pas être obtenue.
Il est impossible de déduire la clé privée correspondante d'une clé publique. Même si l'intermédiaire obtient le certificat, il ne peut pas prétendre être un serveur légitime car il ne peut pas déchiffrer les données cryptées transmises par le client.
Si vous avez besoin que le navigateur ne vous demande pas de risques de sécurité, vous ne pouvez utiliser que des certificats émis par des autorités de certification.
Mais les navigateurs ne font généralement que signaler les risques de sécurité et n'empêchent pas l'accès au site Web. Donc, techniquement, n'importe qui peut générer un certificat, et tant qu'il existe un certificat, la transmission HTTPS du site Web peut être effectuée.
Par exemple, le début 12306 utilisait l'installation manuelle de certificats privés pour obtenir un accès HTTPS.
La vérification du certificat est mise en œuvre à l'aide d'un cryptage asymétrique, mais le processus de transmission utilise un cryptage symétrique et les nombres aléatoires importants dans l'algorithme de cryptage symétrique sont générés et stockés localement. Comment HTTPS garantit-il que les nombres aléatoires ne seront pas volés ?
En fait, HTTPS n'inclut pas de garanties de sécurité pour les nombres aléatoires. HTTPS garantit uniquement la sécurité du processus de transmission, et les nombres aléatoires sont stockés localement. La sécurité locale appartient à une autre catégorie de sécurité. anti-chevaux de Troie et navigation mises à niveau du serveur pour corriger les bugs, etc.
Les données HTTPS sont cryptées dans des circonstances normales, le contenu du paquet capturé par l'outil de capture de paquets après la demande de proxy est crypté et ne peut pas être visualisé directement.
Cependant, comme mentionné ci-dessus, le navigateur ne signalera le risque de sécurité que si l'utilisateur l'autorise, il peut toujours continuer à accéder au site Web et compléter la demande.
Par conséquent, tant que le client est notre propre terminal et que nous l'autorisons, nous pouvons mettre en place un réseau d'intermédiaires, et l'outil de capture de paquets sert d'agent de l'intermédiaire.
Habituellement, l'outil de capture de paquets HTTPS est utilisé pour générer un certificat. L'utilisateur doit installer manuellement le certificat dans le client, puis toutes les requêtes initiées par le terminal terminent l'interaction avec l'outil de capture de paquets via ce certificat.
Ensuite, l'outil de capture de paquets transmet la requête au serveur, et génère enfin le résultat renvoyé par le serveur à la console, puis le renvoie au terminal, bouclant ainsi toute la boucle fermée de la requête.
Puisque HTTPS ne peut pas empêcher la capture de paquets, à quoi sert HTTPS ? HTTPS peut empêcher les utilisateurs d'être surveillés sur les liaisons de communication à leur insu. Il n'offre pas de protection pour les opérations actives de capture de paquets d'octroi de crédit, car les utilisateurs dans ce scénario sont déjà conscients des risques.
Pour empêcher la capture de paquets, une protection de sécurité au niveau de l'application doit être adoptée, telle qu'un cryptage symétrique privé et un renforcement anti-décompilation sur le terminal mobile pour empêcher le piratage des algorithmes locaux.
Ce qui suit est un bref résumé de questions et réponses du texte intégral :
Q : Pourquoi HTTPS est-il sécurisé ?
A : Parce que HTTPS garantit la sécurité de la transmission, empêche la surveillance du processus de transmission, empêche le vol de données et peut confirmer l'authenticité du site Web.
Q : Quel est le processus de transmission HTTPS ?
A : Le client initie une requête HTTPS, le serveur renvoie un certificat, le client vérifie le certificat, et après avoir réussi la vérification, il génère localement un nombre aléatoire utilisé pour transformer l'algorithme de chiffrement symétrique.
Le nombre aléatoire est crypté et transmis au serveur via la clé publique du certificat. Après l'avoir reçu, le serveur déchiffre le nombre aléatoire via la clé privée, et les interactions de données ultérieures sont cryptées et déchiffrées via l'algorithme de cryptage symétrique.
Q : Pourquoi ai-je besoin d'un certificat ?
A : Empêchez les attaques de type « homme du milieu » et fournissez une preuve d'identité pour le site Web.
Q : Les paquets seront-ils capturés lors de l'utilisation de HTTPS ?
A : Les paquets seront capturés. HTTPS empêche uniquement les utilisateurs d'être surveillés à leur insu. Si l'utilisateur accorde activement du crédit, un réseau « intermédiaire » peut être construit et le logiciel proxy peut décrypter le contenu de la transmission.
Partagez un schéma de processus d'apprentissage du HTTPS :
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!