Maison > Problème commun > Entretien avec une grande usine : HTTPS a été demandé trois fois de suite, et la dernière question était de savoir s'il y avait beaucoup de monde

Entretien avec une grande usine : HTTPS a été demandé trois fois de suite, et la dernière question était de savoir s'il y avait beaucoup de monde

Libérer: 2023-08-28 16:43:23
avant
1413 Les gens l'ont consulté

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面试

Avant-propos

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 :

  • Pourquoi HTTPS est-il sûr ?
  • Comment mettre en œuvre le principe sous-jacent du HTTPS ?
  • L'utilisation du HTTPS est-elle nécessairement sûre ?

Cet article approfondira et expliquera le principe de la sécurité du HTTPS.

Le principe de mise en œuvre 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 :

Entretien avec une grande usine : HTTPS a été demandé trois fois de suite, et la dernière question était de savoir s'il y avait beaucoup de monde
img

Étape de vérification du certificat :

  • Le navigateur initie une requête HTTPS.
  • Le serveur renvoie le certificat HTTPS.
  • Le client vérifie si le certificat est légal et déclenche une alarme s'il ne l'est pas.

Étape de transmission des données :

  • Lorsque la légalité du certificat est vérifiée, un numéro aléatoire est généré localement.
  • Cryptez le nombre aléatoire via la clé publique et transmettez le nombre aléatoire crypté au serveur.
  • Le serveur déchiffre le nombre aléatoire grâce à la clé privée.
  • Le serveur construit un algorithme de cryptage symétrique grâce aux nombres aléatoires transmis par le client et crypte le contenu du résultat renvoyé avant de le transmettre.

Pourquoi le cryptage symétrique est-il utilisé pour la transmission de 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.

Pourquoi avez-vous besoin d'une autorité de certification CA pour délivrer un certificat ?

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 :

Entretien avec une grande usine : HTTPS a été demandé trois fois de suite, et la dernière question était de savoir s'il y avait beaucoup de monde

Le principe du processus est le suivant :

  • Les requêtes locales sont détournées (comme le piratage DNS, etc. ), et toutes les demandes sont envoyées au serveur de l'intermédiaire.
  • Le serveur intermédiaire renvoie le propre certificat de l'intermédiaire.
  • Le client crée un nombre aléatoire, crypte le nombre aléatoire via la clé publique du certificat intermédiaire et le transmet à l'intermédiaire, puis utilise le nombre aléatoire pour construire un cryptage symétrique afin de crypter le contenu de la transmission.
  • Étant donné que l'intermédiaire dispose du numéro aléatoire du client, il peut décrypter le contenu grâce à un algorithme de cryptage symétrique.
  • L'intermédiaire utilise le contenu de la demande du client pour lancer une demande sur le site Web habituel.
  • Étant donné que le processus de communication entre l'intermédiaire et le serveur est légal, le site Web habituel renvoie des données cryptées via le canal sécurisé établi.
  • L'intermédiaire décrypte le contenu à l'aide d'un algorithme de cryptage symétrique établi avec le site Web légitime.
  • L'intermédiaire crypte et transmet les données renvoyées par le contenu régulier via l'algorithme de cryptage symétrique établi avec le client.
  • Le client déchiffre les données de résultat renvoyées grâce à l'algorithme de cryptage symétrique établi avec l'intermédiaire.

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 ?

Quelles informations contient le certificat ?

Le certificat contient les informations suivantes :

  • Informations sur l'autorité émettrice
  • Clé publique
  • Informations sur l'entreprise
  • Nom de domaine
  • Période de validité
  • Empreinte digitale

Certificat Quel est le fondement de la légalité ?

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.

Comment le navigateur vérifie-t-il la validité du certificat ?

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 :

  • Vérifiez si le nom de domaine, la période de validité et d'autres informations sont corrects. Le certificat contient ces informations, ce qui facilite la réalisation de la vérification.
  • Déterminez si la source du certificat est légale. Chaque certificat émis peut trouver le certificat racine correspondant selon la chaîne de vérification. Le système d'exploitation et le navigateur stockeront localement le certificat racine de l'organisation faisant autorité. Le certificat racine local peut être utilisé pour compléter la vérification de la source du certificat émis par le correspondant. organisation.
Entretien avec une grande usine : HTTPS a été demandé trois fois de suite, et la dernière question était de savoir s'il y avait beaucoup de monde
  • ** 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.

Seules les autorités de certification peuvent-elles générer des certificats ?

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.

Entretien avec une grande usine : HTTPS a été demandé trois fois de suite, et la dernière question était de savoir s'il y avait beaucoup de monde

Que dois-je faire si le numéro aléatoire local est volé ?

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.

Mes paquets seront-ils capturés si j'utilise HTTPS ?

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.

Résumé

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 :

Entretien avec une grande usine : HTTPS a été demandé trois fois de suite, et la dernière question était de savoir s'il y avait beaucoup de monde

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!

Étiquettes associées:
source:Java后端技术全栈
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal