Comment HTTPS assure-t-il la sécurité du Web ? (exemple de code)

Le contenu de cet article porte sur la façon dont HTTPS assure la sécurité du Web ? (Exemple de code) a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer. J'espère que cela vous sera utile.

HTTPS (nom complet : HyperText Transfer Protocol over Secure Socket Layer) a pour but d'assurer la sécurité de la transmission des données entre le client et le serveur. Au cours des deux dernières années, les géants de l'Internet tels que Google, Baidu et Facebook ont ​​commencé à promouvoir vigoureusement le HTTPS. De nombreuses grandes sociétés Internet nationales et étrangères ont également activé le HTTPS complet. C'est également la tendance future du développement d'Internet. Pour les ingénieurs front-end, comprendre les principes du HTTPS est également un cours obligatoire.
2019 n'est pas loin de l'utilisation du HTTPS sur l'ensemble du réseau. Voici quelques exigences avancées par les grandes sociétés Internet pour encourager l'utilisation du HTTPS :
1 L'algorithme du moteur de recherche de Google autorise les sites Web qui utilisent le HTTPS. pour être plus efficace dans les recherches Classé plus haut ;
2. Apple exige que toutes les applications de l'App Store utilisent des connexions cryptées HTTPS
3. Les mini-programmes WeChat nécessitent également l'utilisation du protocole HTTPS ; Une nouvelle génération de HTTP/ 2 La prise en charge du protocole doit être basée sur HTTPS ;
5. La nouvelle version de Chrome a marqué le site Web du protocole HTTP comme
non sécurisé

<.>Danger caché : Pourquoi ajouter S à HTTP ?

Le protocole HTTP est assez excellent et pratique depuis sa création. Cependant, HTTP n'a pas que des bons côtés, tout a deux côtés, et ses défauts sont également évidents :

Les communications sont transmises en texte clair et le contenu peut être écouté
L'identité de la partie communicante n'est pas vérifiée, il est donc possible de rencontrer un déguisement
L'intégrité du message ne peut être prouvée, il peut donc avoir été falsifié
De plus, HTTP lui-même présente de nombreuses lacunes. De plus, il existe également des lacunes (qui peuvent également être considérées comme des vulnérabilités ou des failles de sécurité) dans les applications réelles de certains serveurs Web spécifiques et navigateurs Web spécifiques. De plus, les applications Web développées avec des langages de programmation tels que Java et PHP peuvent exister. Il s'agit également de failles de sécurité.

1. Les communications utilisant du texte clair peuvent être écoutées.

Étant donné que HTTP lui-même n'a pas de fonction de cryptage, il ne peut pas être utilisé pour crypter l'intégralité de la communication (communication utilisant le Protocole HTTP) (le contenu des requêtes et des réponses) sont cryptés. Par conséquent, les messages HTTP sont envoyés en texte clair. Si vous voulez savoir pourquoi le fait de ne pas chiffrer la communication est un inconvénient, c'est parce que, selon le mécanisme de fonctionnement de la suite de protocoles TCP/IP, le contenu de la communication peut être aperçu sur toutes les lignes de communication.

Ce qu'on appelle Internet est composé de réseaux qui peuvent être connectés au monde entier. Peu importe où le serveur dans le monde communique avec le client, certains équipements réseau, câbles optiques, ordinateurs, etc. ne peut pas être une propriété privée, il n'est donc pas exclu qu'un voyeurisme malveillant puisse se produire dans un certain lien.

Même si la communication a été cryptée, le contenu de la communication sera consulté, ce qui équivaut à une communication non cryptée. Cela signifie simplement que si la communication est cryptée, il peut être impossible de déchiffrer la signification des informations du message, mais le message crypté lui-même sera toujours visible.
Écouter les communications sur le même segment n'est pas difficile. Collectez simplement les paquets de données circulant sur Internet. L’analyse des paquets de données collectés peut être confiée à ces outils de capture ou de reniflage de paquets.

2. Le fait de ne pas vérifier l'identité de la partie communicante peut entraîner un déguisement.

La demande et la réponse dans le protocole HTTP ne confirmeront pas la partie communicante. En d'autres termes, il existe des problèmes similaires, tels que « si le serveur est l'hôte réellement spécifié par l'URI dans la requête, et si la réponse renvoyée est réellement renvoyée au client qui a réellement fait la requête ».

Pendant la communication selon le protocole HTTP, puisqu'il n'y a pas d'étape de traitement pour confirmer la partie communicante, n'importe qui peut envoyer une requête en même temps, tant que le serveur reçoit la requête, à condition de connaître l'adresse IP et le numéro de port de. l'expéditeur n'est pas limité par le serveur Web. , peu importe qui est l'autre partie, une réponse sera renvoyée, il y aura donc divers dangers cachés :

Il est impossible de déterminer Si le serveur Web sur lequel la requête est envoyée à la cible est le serveur qui renvoie la réponse selon la véritable intention, il peut s'agir d'un serveur Web déguisé.
Il est impossible de déterminer si le client renvoyé par la réponse est le client qui a reçu la réponse selon la véritable intention.
Impossible de déterminer si l'autre partie avec laquelle vous communiquez dispose de droits d'accès. Parce que certains serveurs Web stockent des informations importantes qui pointent vers les autorisations pour les communications envoyées à des utilisateurs spécifiques.
Il est impossible de déterminer d'où vient la demande et qui l'a formulée.
Les demandes qui n'auront aucun sens dans les délais seront acceptées dans leur intégralité. Impossible de prévenir les attaques DoS (attaques par déni de service, attaques par déni de service) lors de requêtes massives.

3. L'intégrité du message ne peut être prouvée et peut avoir été falsifiée

La soi-disant exhaustivité fait référence à l'exactitude des informations. Le fait de ne pas démontrer leur exhaustivité signifie généralement qu’il est impossible de juger si les informations sont exactes.
Par conséquent, même si la demande ou le contenu correspondant a été falsifié pendant la période suivant l'envoi de la demande ou de la réponse et avant que l'autre partie ne la reçoive, il n'y a aucun moyen de le savoir.
En d'autres termes, il n'y a aucun moyen de confirmer que la demande et la réponse envoyées sont les mêmes que la demande et la réponse reçues. Le contenu du fichier peut avoir été remplacé par un autre contenu pendant la transmission. Dans ce cas, une attaque dans laquelle la demande ou la réponse est interceptée par un attaquant pendant la transmission et falsifie le contenu est appelée attaque Man-in-the-Middle (MITM). ).

Solution : HTTP + Cryptage + Authentification + Protection de l'intégrité = HTTPS

Avec autant de lacunes de HTTP mentionnées ci-dessus, nous devons naturellement les résoudre en HTTPS. Voyons comment HTTPS assure la sécurité de notre transmission de données.

1. HTTPS est en fait HTTP enveloppé dans un shell SSL

HTTPS n'est pas un nouveau protocole au niveau de la couche application. La partie interface de communication HTTP est remplacée par les protocoles SSL (Secure Socket Layer) et TLS (Transport Layer Security).
Habituellement, HTTP communique directement avec TCP. Lorsque vous utilisez SSL, il communique d'abord avec SSL, puis SSL communique avec TCP. En termes simples, HTTP utilisé en combinaison avec SSL est appelé HTTPS (HTTP Secure, Hypertext Transfer Security Protocol) ou HTTP sur SSL.
Après avoir adopté SSL, HTTP dispose des fonctions de cryptage, de certificat et de protection de l'intégrité de HTTPS. SSL est un protocole indépendant de HTTP, donc non seulement le protocole HTTP, mais d'autres protocoles tels que SMTP et Telnet qui s'exécutent au niveau de la couche application peuvent être utilisés avec le protocole SSL. On peut dire que SSL est aujourd’hui la technologie de sécurité réseau la plus utilisée dans le monde.

Principe de cryptage de HTTPS

Dans les algorithmes de cryptage modernes, l'algorithme de cryptage est public, et le L'algorithme de cryptage est public. La clé est gardée secrète. De cette manière, la sécurité de la méthode de cryptage est préservée.

Le cryptage et le décryptage nécessitent une clé. Sans la clé, il n'y a aucun moyen de déchiffrer le mot de passe. En d’autres termes, toute personne possédant la clé peut déchiffrer le texte chiffré.

HTTPS utilise une technologie de cryptage asymétrique et une technologie de cryptage symétrique dans le processus de cryptage.

Algorithme de cryptage symétrique

Utilise la méthode de cryptage du système de cryptographie à clé unique. La même clé peut crypter et déchiffrer les informations en même temps. Cette méthode de cryptage est appelée cryptage symétrique, également connue sous le nom de cryptage symétrique. Cryptage à clé unique.

L'algorithme de chiffrement symétrique sera appelé ci-dessous algorithme de chiffrement à clé partagée.

Supposons maintenant que SSL utilise un algorithme de cryptage symétrique pendant le processus de communication, ce qui signifie que le client et le serveur partagent une clé en même temps.

Ainsi, pour chiffrer à l'aide d'une clé partagée, la clé doit être envoyée à l'autre partie. À ce stade, si le processus de communication est surveillé et que la clé est obtenue par l'attaquant, la signification du cryptage sera alors perdue.

Alors, y a-t-il un moyen de résoudre ce problème ? La réponse est oui, c'est-à-dire utilisez deux clés.

Regardons l'algorithme de chiffrement asymétrique utilisant deux clés.

Algorithme de chiffrement asymétrique

Contrairement à l'algorithme de chiffrement symétrique, l'algorithme de chiffrement asymétrique nécessite deux clés pour le chiffrement et le déchiffrement. Ces deux clés sont appariées, à savoir la clé publique et la clé publique. (clé publique) et clé privée (clé privée).

Généralement, la clé publique peut être rendue publique et est principalement utilisée pour chiffrer du texte brut. En conséquence, la clé privée ne peut pas être rendue publique et est utilisée pour déchiffrer le texte chiffré par la clé publique.

Il est à noter que le texte chiffré crypté par la clé publique ne peut être déchiffré que par la clé privée correspondante, tandis que le texte chiffré crypté par la clé privée peut être déchiffré par la clé publique correspondante.

Ci-dessus, le cryptage à clé publique et le déchiffrement à clé privée sont utilisés pour le cryptage, et le cryptage à clé privée et le déchiffrement à clé publique sont utilisés pour la signature. Les utilisations associées seront discutées plus tard.

L'algorithme de chiffrement asymétrique sera appelé ci-dessous algorithme de chiffrement à clé publique.

Alors maintenant, supposons que le serveur génère une paire de clé publique et de clé secrète.

Lorsque le client fait une requête et négocie avec le serveur pour la première fois, le serveur génère une paire de clés publiques et privées.

Ensuite, le serveur envoie la clé publique au client (texte brut, aucun cryptage n'est requis). Après l'avoir reçue, le client génère aléatoirement une clé et utilise la clé publique envoyée par le serveur pour le cryptage.

Ensuite, le client envoie la clé chiffrée avec la clé publique au serveur. Une fois que le serveur l'a reçue, il utilise la clé privée couplée pour la déchiffrer et obtient la clé générée aléatoirement par le client.

À l'heure actuelle, les clés détenues par le client et le serveur sont les mêmes. À ce stade, le processus d’échange de clés est terminé.

Ensuite, la méthode de cryptage à clé partagée décrite ci-dessus peut être utilisée pour crypter le démarrage de la communication.

Il est possible d'utiliser

en même temps. Certains amis se demanderont pourquoi se donner la peine d'utiliser le cryptage asymétrique, puis d'obtenir la même clé pour la communication cryptée à clé partagée Woollen. tissu?

Étant donné que le chiffrement à clé publique est plus complexe à traiter que le chiffrement à clé partagée, l'efficacité de l'utilisation du chiffrement à clé publique pendant la communication est très faible.

Nous devons donc utiliser un cryptage asymétrique pour garantir la sécurité de la clé pendant le processus de partage de clé, puis utiliser l'algorithme de cryptage symétrique pendant le processus de communication. C'est la méthode de conception la plus raisonnable. tout en garantissant la performance.

Par conséquent, HTTPS utilise un mécanisme de chiffrement hybride qui utilise à la fois le chiffrement à clé partagée et le chiffrement à clé publique. Le chiffrement à clé publique est utilisé lors de la phase d'échange de clés, et le chiffrement à clé partagée est utilisé lors de la phase d'échange de messages de communication ultérieure.

Ce qui précède est probablement le processus d'utilisation du cryptage symétrique et du cryptage asymétrique. Il semble que le processus soit parfait, mais il reste un problème : comment garantir l'exactitude de la clé publique transmise par le serveur. En d’autres termes, il s’agit de garantir qu’il ne puisse pas être intercepté et falsifié.

Utilisez des certificats pour garantir l'exactitude de la clé publique

Si vous vous préparez maintenant à établir une communication de cryptage à clé publique avec un serveur, comment prouver que le client a reçu La clé publique est-elle la clé publique émise par le serveur comme prévu initialement ? Il est possible que lors de la transmission de la clé publique, la véritable clé publique ait été remplacée par l'attaquant.

Pour résoudre ce problème, vous pouvez utiliser des certificats de clé publique émis par les autorités de certification numérique et leurs autorités associées.

Ce qui suit décrit le processus commercial de l'autorité de certification de certificat numérique (CA) :

Tout d'abord, l'opérateur du serveur demande une clé publique à l'autorité de certification numérique. Une fois que l'autorité de certification du certificat numérique a déterminé l'identité du demandeur, elle signera numériquement la clé publique appliquée, puis distribuera la clé publique signée, placera la clé publique dans le certificat de clé publique et la liera à Together.

Traduisons le paragraphe ci-dessus en langue vernaculaire :
Tout d'abord, l'AC délivrera un certificat au demandeur. Le contenu de ce certificat comprend : l'émetteur, l'objet du certificat et ce qui est inclus avec. l'application serveur. Clé publique, algorithme de chiffrement du serveur, algorithme HASH utilisé, délai d'expiration du certificat, etc.
Ensuite, effectuez une évaluation HASH sur le contenu mentionné ci-dessus pour obtenir une valeur HASH.

Ensuite, utilisez la clé privée de l'AC pour chiffrer, complétant ainsi la signature numérique. Après cryptage avec la clé privée de l'AC, une signature semblable à une empreinte digitale humaine est générée. Toute tentative de falsification du certificat sera découverte par la signature numérique.
Enfin, attachez la signature numérique à la fin du certificat numérique et transmettez-la au serveur.
Ensuite, le serveur enverra au client le certificat de clé publique émis par l'autorité de certification de certificat numérique. A ce moment, le client peut utiliser la clé publique de l'autorité de certification numérique pour la vérifier. Une fois la vérification réussie, le client peut être sûr que la clé publique est fiable.

Traduisons-le en vernaculaire :
Une fois que le client a obtenu ce certificat numérique, il peut utiliser la clé publique correspondant à la clé privée de l'AC pour déchiffrer la signature numérique à la fin du certificat numérique et obtenir le valeur de HASH originale.
Ensuite, le client calcule la valeur HASH pour le contenu du certificat selon l'algorithme HASH du certificat. Si la valeur HASH déchiffrée par la clé publique de l'AC est la même que la valeur HASH obtenue par calcul, alors l'authentification réussit, sinon elle échoue.
Si l'authentification réussit, vous pouvez obtenir la clé publique du serveur.

D'où vient la clé publique CA sur le client ?
Lorsque la plupart des développeurs de navigateurs publient des versions, ils intègrent à l'avance les clés publiques des autorités de certification couramment utilisées. De cette manière, il est pratique pour le client de vérifier l'authenticité du certificat numérique.

Le processus spécifique est le suivant (le processus de signature numérique est simplifié sur l'image) :

Il est réellement utilisé ici Algorithme de chiffrement asymétrique, sauf que maintenant cet algorithme de chiffrement est utilisé pour la signature au lieu du chiffrement.

En utilisant le cryptage par clé privée et le déchiffrement par clé publique, le détenteur de la clé publique est utilisé pour vérifier si le contenu crypté par la clé privée a été falsifié, mais il n'est pas utilisé pour garantir si le contenu a été obtenu par d'autres.

L'utilisation du cryptage par clé publique et du déchiffrement par clé privée est l'inverse. Cela ne garantit pas que les informations seront interceptées et falsifiées par d'autres, mais cela garantit que les informations ne pourront pas être obtenues par un intermédiaire.

Certificat client

Non seulement les certificats de serveur peuvent être utilisés en HTTPS, mais également les certificats clients peuvent être utilisés. Utilisez le certificat client pour l'authentification client, qui a la même fonction que le certificat serveur.

Étant donné que le client doit installer le certificat client pour obtenir le certificat, il est également confronté au problème du coût.

Par conséquent, la situation actuelle est que les autorités de certification de très haute sécurité peuvent obtenir des certificats clients, mais uniquement pour des services spécifiques. Par exemple, les entreprises qui peuvent prendre en charge le coût des certificats clients.

Par exemple, la banque en ligne de la banque utilise des certificats clients. Lors de la connexion aux services bancaires en ligne, l'utilisateur doit non seulement confirmer la saisie de son identifiant et de son mot de passe, mais également le certificat client de l'utilisateur est requis pour confirmer si l'utilisateur accède aux services bancaires en ligne à partir d'un terminal spécifique.

Mécanisme de communication sécurisé de HTTPS

Afin de mieux comprendre HTTPS, Xiaosi a dessiné le schéma suivant pour que chacun puisse observer les étapes de communication de HTTPS :

Étape 1 : Le le client démarre la communication SSL en envoyant un message Client Hello. Le message contient la version spécifiée de SSL prise en charge par le client et une liste des composants de chiffrement (l'algorithme de chiffrement utilisé, la longueur de la clé, etc.).

Étape 2 : Lorsque le serveur peut effectuer une communication SSL, il répondra par un message Server Hello. Comme le client, la version SSL et les composants de chiffrement sont inclus dans le message. Le contenu du composant cryptographique du serveur est filtré du composant cryptographique du client reçu.

Étape 3 : Le serveur envoie ensuite le message Certificat. Le message contient un certificat de clé publique.

Étape 4 : Enfin, le serveur envoie un message Server Hello Done pour informer le client que la phase initiale de négociation de négociation SSL est terminée.

Étape 5 : Une fois la première négociation SSL terminée, le client répond avec un message Client Key Exchange. Le message contient une chaîne de mot de passe aléatoire appelée secret pré-maître utilisée dans le cryptage des communications. Le message a été chiffré avec la clé publique de l'étape 3.

Étape 6 : Le client continue ensuite d'envoyer des messages Change Cipher Spec. Ce message indiquera au serveur que les communications après ce message seront cryptées à l'aide de la clé secrète pré-maître.

Étape 7 : Le client envoie un message Terminé. Ce message contient la valeur de validation globale de tous les messages connectés jusqu'à présent. La réussite de cette négociation de prise de contact dépend de la capacité du serveur à déchiffrer correctement le message.

Étape 8 : Le serveur envoie également un message Change Cipher Spec.

Étape 9 : Le serveur envoie également un message Terminé.

Étape 10 : Après l'échange des messages Terminé entre le serveur et le client, la connexion SSL est établie. Bien entendu, la communication sera protégée par SSL. À partir de là, commence la communication avec le protocole de la couche application, c'est-à-dire l'envoi de requêtes HTTP.

Étape 11 : Communication du protocole de la couche application, c'est-à-dire envoi d'une réponse HTTP.

Étape 12 : Enfin, le client se déconnecte. Lors de la déconnexion, un message close_notify est envoyé. Certaines omissions ont été faites dans la figure ci-dessus. Après cette étape, un message TCP FIN est envoyé pour fermer la communication avec TCP.

Dans le processus ci-dessus, lorsque la couche d'application envoie des données, elle ajoute un résumé de message appelé MAC (Message Authentication Code). MAC peut vérifier si le message a été falsifié, protégeant ainsi l'intégrité du message.

Maintenant, une question se pose : à quoi servent les trois nombres aléatoires générés dans l'ensemble du processus ? De plus, lors d'une communication HTTP ultérieure, quelle clé est utilisée pour le cryptage et comment garantir l'intégrité du message.

Regardez l'image ci-dessous.

Pour le client :

Après avoir généré le secret pré-maître, il combinera les nombres aléatoires A et B d'origine , utilisez l'algorithme DH pour calculer un secret principal, puis dérivez le secret de hachage et le secret de session en fonction de ce secret principal.

Pour le serveur :

Après avoir déchiffré et obtenu le secret pré-maître, il combinera les nombres aléatoires originaux A et B et utilisera l'algorithme DH pour calculer un secret maître, puis utilisera ce Le secret principal dérive le secret de hachage et le secret de session.

Le secret principal sur le client et le serveur est dérivé de trois nombres aléatoires. Il ne sera pas transmis sur le réseau. Seules les deux parties le connaissent, et aucun tiers ne le saura. Dans le même temps, le secret de session et le secret de hachage dérivés par le client sont exactement les mêmes que ceux du serveur.

Alors maintenant, si les deux parties commencent à utiliser un algorithme de chiffrement symétrique pour communiquer, lequel sera utilisé comme clé partagée ? Le processus est le suivant :

Les deux parties utilisent un algorithme de chiffrement symétrique pour chiffrer, utilisent un secret de hachage pour effectuer une opération sur le message HTTP afin de générer un MAC, le joignent à la fin du message HTTP, puis utilisez le secret de session pour crypter toutes les données (HTTP+MAC), puis envoyez-les.

Le récepteur utilise d'abord le secret de session pour décrypter les données, puis obtient HTTP+MAC, puis utilise le même algorithme pour calculer son propre MAC. Si les deux MAC sont égaux, cela prouve que les données ne l'ont pas été. été trafiqué.

À ce stade, l'ensemble du processus a été introduit.

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!