Pourquoi HTTPS est-il plus sécurisé que HTTP ?

Avant-propos

Ces dernières années, Internet a subi d'énormes changements, notamment le protocole HTTP que nous avons habitué à , est progressivement remplacé par le protocole HTTPS. Avec la promotion conjointe des navigateurs, des moteurs de recherche, des institutions CA et des grandes sociétés Internet, Internet a inauguré « l'ère du cryptage HTTPS ». HTTPS remplacera complètement HTTP comme moyen de transport. dans les prochaines années.

Après avoir lu cet article, j'espère que vous comprendrez :

Quels sont les problèmes avec la communication HTTP

Comment HTTPS s'améliore Quels sont les problèmes avec HTTP

Quel est le principe de fonctionnement de HTTPS

1 Qu'est-ce que HTTPS

HTTPS établit une couche de cryptage SSL au-dessus de HTTP et crypte le données transmises. Il fait partie de la version sécurisée du protocole HTTP. Il est désormais largement utilisé pour les communications sensibles en matière de sécurité sur le World Wide Web, telles que les paiements transactionnels.

Les principales fonctions de HTTPS sont :

(1) Crypter les données et établir un canal de sécurité des informations pour garantir la sécurité des données pendant la transmission

(2) Effectuer une véritable authentification d'identité ; sur le serveur du site Web.

Nous utilisons souvent la communication HTTPS sur la page de connexion Web et l'interface de paiement. Lors de l'utilisation de la communication HTTPS, http:// n'est plus utilisé, mais https:// est utilisé à la place. De plus, lorsque le navigateur accède à un site Web avec une communication HTTPS valide, une marque verrouillée apparaîtra dans la barre d'adresse du navigateur. La façon dont HTTPS est affiché varie en fonction du navigateur.

2. Pourquoi HTTPS est nécessaire

Dans le protocole HTTP, il peut y avoir des problèmes de sécurité tels que le vol d'informations ou le déguisement d'identité. L'utilisation du mécanisme de communication HTTPS peut prévenir efficacement ces problèmes. Ensuite, comprenons d'abord les problèmes du protocole HTTP :

La communication utilise du texte brut (non crypté) et le contenu peut être écouté

Étant donné que HTTP lui-même n'a pas de fonction de cryptage, il ne peut pas crypter l'intégralité de la communication (le contenu des requêtes et des réponses communiquées à l'aide du protocole HTTP). Autrement dit, les messages HTTP sont envoyés en texte clair (faisant référence à des messages non chiffrés).

Les failles du protocole HTTP en clair sont une cause importante de problèmes de sécurité tels que les fuites de données, la falsification des données, le détournement de trafic et les attaques de phishing. Le protocole HTTP ne peut pas crypter les données et toutes les données de communication « circulent à nu » sur le réseau en texte brut. Grâce à un équipement de détection de réseau et à certains moyens techniques, le contenu des messages HTTP peut être restauré.

L'intégrité du message ne peut être prouvée, il peut donc être falsifié.

La soi-disant intégrité fait référence à l'exactitude de l'information. Le fait de ne pas démontrer leur exhaustivité signifie généralement qu’il est impossible de juger si les informations sont exactes. Étant donné que le protocole HTTP ne peut pas prouver l'intégrité des messages de communication, il n'y a aucun moyen de savoir même si le contenu de la demande ou de la réponse a été falsifié pendant la période suivant l'envoi de la demande ou de la réponse jusqu'à ce qu'elle soit reçue par l'autre partie. . En d’autres termes, il n’existe aucun moyen de confirmer que la demande/réponse envoyée et la demande/réponse reçue sont identiques.

L'identité de la partie communicante n'est pas vérifiée, le masquage est donc possible.

Les requêtes et réponses dans le protocole HTTP ne confirment pas la partie communicante. Lors d'une communication selon le protocole HTTP, puisqu'il n'y a aucune étape de traitement pour confirmer la partie communicante, n'importe qui peut lancer une demande. De plus, tant que le serveur reçoit la requête, il renverra une réponse peu importe qui est l'autre partie (mais seulement si l'adresse IP et le numéro de port de l'expéditeur ne sont pas restreints par le serveur Web)

Le protocole HTTP ne peut pas être vérifié Quant à l'identité de la partie communicante, n'importe qui peut forger un faux serveur pour tromper les utilisateurs, réalisant ainsi une « fraude par phishing » qui ne peut pas être détectée par les utilisateurs.

En regardant le protocole HTTPS, il présente les avantages suivants par rapport au protocole HTTP (détaillés ci-dessous) :

Confidentialité des données : le contenu est crypté symétriquement et chaque connexion génère une clé de cryptage unique

Intégrité des données : la transmission du contenu est vérifiée en intégrité

Authentification de l'identité : un tiers ne peut pas falsifier l'identité du serveur (client)

Comment HTTPS résout-il le problème. au-dessus des problèmes de HTTP ?

HTTPS n'est pas un nouveau protocole au niveau de la couche application. Seule la partie interface de communication HTTP est remplacée par les protocoles SSL et TLS.

Habituellement, HTTP communique directement avec TCP. Lors de l'utilisation de SSL, il évolue pour communiquer d'abord avec SSL, puis SSL communique avec TCP. En bref, ce qu'on appelle HTTPS est en fait HTTP enveloppé dans le shell du protocole SSL.

Après avoir adopté SSL, HTTP dispose des fonctions de cryptage, de certificat et de protection de l'intégrité du HTTPS. En d’autres termes, HTTP plus le traitement du cryptage, l’authentification et la protection de l’intégrité sont HTTPS.

Les principales fonctions du protocole HTTPS reposent essentiellement sur le protocole TLS/SSL. L'implémentation des fonctions de TLS/SSL repose principalement sur trois types d'algorithmes de base : la fonction de hachage, le cryptage symétrique et le cryptage asymétrique, qui utilise le cryptage asymétrique. chiffrement Implémente l'authentification d'identité et la négociation de clé. L'algorithme de chiffrement symétrique utilise la clé négociée pour chiffrer les données et vérifie l'intégrité des informations en fonction de la fonction de hachage.

1. Résoudre le problème de l'écoute clandestine du contenu - Cryptage

Méthode 1. Cryptage symétrique

Cette méthode utilise la même clé pour le cryptage et le déchiffrement. Les clés sont utilisées pour le cryptage et le déchiffrement. Le mot de passe ne peut pas être déchiffré sans la clé, et inversement, toute personne possédant la clé peut le déchiffrer.

Lors du cryptage par cryptage symétrique, la clé doit également être envoyée à l'autre partie. Mais comment le transférer en toute sécurité ? Lorsque les clés sont transmises sur Internet, si la communication est écoutée, les clés peuvent tomber entre les mains d'un attaquant et l'objectif du cryptage sera perdu. Vous devez également trouver un moyen de conserver la clé reçue en toute sécurité.

Méthode 2. Cryptage asymétrique

Le cryptage à clé publique utilise une paire de clés asymétriques. L’une est appelée clé privée et l’autre est appelée clé publique. Comme son nom l’indique, la clé privée ne peut être connue de personne d’autre, tandis que la clé publique peut être librement divulguée et accessible à tous.

En utilisant le cryptage à clé publique, la partie qui envoie le texte chiffré utilise la clé publique de l'autre partie pour le cryptage. Une fois que l'autre partie a reçu les informations cryptées, elle utilise sa propre clé privée pour les déchiffrer. De cette façon, il n’est pas nécessaire d’envoyer la clé privée utilisée pour le déchiffrement, et il n’y a pas lieu de craindre que la clé soit écoutée et volée par un attaquant.

La caractéristique du cryptage asymétrique est que les informations sont transmises un à plusieurs. Le serveur n'a besoin de conserver qu'une seule clé privée pour effectuer une communication cryptée avec plusieurs clients.

Cette méthode présente les inconvénients suivants :

La clé publique est publique, donc après avoir intercepté les informations cryptées par la clé privée, les pirates peuvent utiliser la clé publique pour décrypter et obtenir le contenu

La clé publique ne contient pas les informations du serveur. L'utilisation d'algorithmes de chiffrement asymétrique ne peut garantir la légitimité de l'identité du serveur. Il existe un risque d'attaque de l'homme du milieu envoyée par le serveur. le serveur vers le client peut être intercepté et falsifié par l'intermédiaire pendant le processus de transmission

L'utilisation du cryptage asymétrique prend un certain temps dans le processus de cryptage et de décryptage des données, ce qui réduit l'efficacité de la transmission des données

 ;

Méthode 3. Cryptage symétrique + cryptage asymétrique (HTTPS utilise cette méthode)

L'avantage d'utiliser une clé symétrique est que l'efficacité du décryptage est plus rapide. L'avantage d'utiliser une clé asymétrique est que le contenu transmis. ne peut pas être piraté, car même si vous interceptez les données, mais que vous n'avez pas la clé privée correspondante, vous ne pouvez pas pirater le contenu. Par exemple, vous prenez un coffre-fort, mais vous ne pouvez pas l'ouvrir sans la clé du coffre-fort. Ensuite, nous combinerons le cryptage symétrique et le cryptage asymétrique, exploiterons pleinement leurs avantages respectifs, utiliserons le cryptage asymétrique dans l'étape d'échange de clés et utiliserons le cryptage symétrique dans les étapes ultérieures de communication et d'échange de messages.

La méthode spécifique est la suivante : la partie qui envoie le texte chiffré utilise la clé publique de l'autre partie pour crypter la "clé symétrique", puis l'autre partie utilise sa propre clé privée pour déchiffrer et obtenir la "clé symétrique". Cela garantit que la communication est effectuée à l'aide d'un cryptage symétrique en partant du principe que les clés échangées sont sécurisées. Par conséquent, HTTPS utilise un mécanisme de chiffrement hybride qui utilise à la fois le chiffrement symétrique et le chiffrement asymétrique.

2. Résoudre le problème d'une éventuelle falsification des messages - signature numérique

Pendant le processus de transmission réseau, elle doit passer par de nombreux nœuds intermédiaires. Bien que les données ne puissent pas être déchiffrées, elles peuvent l'être. falsifié. Comment le vérifier? Qu'en est-il de l'intégrité des données? ----Vérifiez la signature numérique.

Les signatures numériques ont deux fonctions :

Elles peuvent confirmer que le message est bien signé et envoyé par l'expéditeur, car d'autres ne peuvent pas falsifier la signature de l'expéditeur.

Les signatures numériques peuvent déterminer l'intégrité du message et prouver si les données n'ont pas été falsifiées.

Comment générer une signature numérique :

Utilisez une fonction de hachage pour générer un résumé de message d'un morceau de texte, puis cryptez-le avec les informations privées de l'expéditeur. clé pour générer une signature numérique, et le texte original est envoyé ensemble au destinataire. L'étape suivante est le processus par lequel le destinataire vérifie la signature numérique.

Processus de vérification de la signature numérique :

Le destinataire ne peut utiliser que la clé publique de l'expéditeur pour déchiffrer les informations de résumé cryptées, puis utiliser la fonction HASH pour le texte original obtenu génère des informations récapitulatives, qui sont comparées aux informations récapitulatives obtenues à l'étape précédente. S'ils sont identiques, cela signifie que les informations reçues sont complètes et n'ont pas été modifiées pendant le processus de transmission. Sinon, cela signifie que les informations ont été modifiées, la signature numérique peut donc vérifier l'intégrité des informations.

Supposons que la transmission du message se produise entre Kobe et James. James envoie le message à Kobe avec la signature numérique. Une fois que Kobe a reçu le message, il peut vérifier que le message reçu a été envoyé par James en vérifiant la signature numérique. Bien entendu, le principe de ce processus est que Kobe connaît la clé publique de James. La clé du problème est que, comme le message lui-même, la clé publique ne peut pas être envoyée directement à Kobe via un réseau non sécurisé, ni comment prouver que la clé publique obtenue appartient à James.

À l'heure actuelle, il est nécessaire d'introduire une autorité de certification (CA). Il n'y a pas beaucoup d'autorités de certification. Le client Kobe dispose de certificats intégrés de toutes les autorités de certification de confiance. L'autorité de certification génère un certificat après avoir signé numériquement la clé publique de James (et d'autres informations).

3. Résoudre le problème selon lequel l'identité de la partie communicante peut être masquée - certificat numérique

L'autorité de certification du certificat numérique est dans la position d'un organisme tiers digne de confiance pour les deux le client et le serveur.

Présentons le processus métier de l'autorité de certification des certificats numériques :

L'opérateur du serveur soumet la clé publique, les informations organisationnelles et les informations personnelles (nom de domaine) au agence tierce CA) et d'autres informations et demander la certification ;

CA vérifie l'authenticité des informations fournies par le demandeur par divers moyens, notamment en ligne et hors ligne, par exemple si l'organisation existe, si l'entreprise est légale, si elle est propriétaire du nom de domaine, etc.

Si les informations sont approuvées, l'AC délivrera un document-certificat de certification au demandeur. Le certificat contient les informations suivantes : la clé publique du demandeur, les informations organisationnelles et personnelles du demandeur, les informations de l'autorité émettrice CA, la durée de validité, le numéro de série du certificat et d'autres informations en texte brut, et contient également une signature. L'algorithme de génération de signature : utilisez d'abord une fonction de hachage pour calculer le résumé des informations publiques en clair, puis utilisez la clé privée de l'autorité de certification pour chiffrer le résumé des informations. Le texte chiffré est la signature

Le client envoie. le message au serveur Lorsque le serveur fait une demande, le serveur renvoie le fichier de certificat ;

Le client lit les informations en clair pertinentes dans le certificat, utilise la même fonction de hachage pour calculer le résumé des informations, puis utilise la clé publique de l'autorité de certification correspondante pour déchiffrer la signature. Les données sont comparées au résumé d'informations du certificat. Si elles sont cohérentes, la légitimité du certificat peut être confirmée, c'est-à-dire que la clé publique du serveur est digne de confiance.

Le client vérifiera également les informations sur le nom de domaine, la durée de validité et d'autres informations liées au certificat ; le client disposera d'informations de certificat de confiance intégrées (y compris la clé publique si l'autorité de certification n'est pas fiable). l'AC correspondante ne sera pas trouvée, le certificat sera également jugé illégal.

4. Flux de travail HTTPS

1. Le client lance une requête HTTPS (telle que https://juejin.im/user Selon RFC2818, le client connaît le). Port 443 (par défaut) du serveur auquel vous devez vous connecter.

2. Le serveur renvoie le certificat de clé publique préconfiguré au client.

3. Le Client vérifie le certificat de clé publique : par exemple, s'il est dans la période de validité, si l'objet du certificat correspond au site demandé par le Client, s'il est dans la liste de révocation CRL, s'il est son certificat de niveau supérieur est valide, il s'agit d'un processus récursif jusqu'à ce que le certificat racine soit vérifié (le certificat racine intégré au système d'exploitation ou le certificat racine intégré au client). Si la vérification réussit, continuez, sinon un message d'avertissement s'affichera.

4. Le client utilise un générateur de nombres pseudo-aléatoires pour générer une clé symétrique utilisée pour le cryptage, puis crypte la clé symétrique avec la clé publique du certificat et l'envoie au serveur.

5. Le serveur utilise sa propre clé privée pour déchiffrer le message et obtenir la clé symétrique. À ce stade, le client et le serveur détiennent la même clé symétrique.

6. Le serveur utilise une clé symétrique pour crypter le « contenu en texte brut A » et l'envoie au client.

7.Le client utilise la clé symétrique pour déchiffrer le texte chiffré de la réponse et obtient le « contenu en texte clair A ».

8. Le client lance à nouveau une requête HTTPS, en utilisant la clé symétrique pour chiffrer le « contenu en texte brut B » demandé, puis le serveur utilise la clé symétrique pour déchiffrer le texte chiffré et obtenir le « contenu en texte clair B ».

5. La différence entre HTTP et HTTPS

HTTP est un protocole de transmission en texte brut, et le protocole HTTPS est un réseau construit par le protocole SSL+HTTP qui peut effectuer protocole de transmission crypté et d'authentification d'identité, plus sécurisé que le protocole HTTP.

Concernant la sécurité, la métaphore la plus simple pour décrire la relation entre les deux est que les camions transportant des marchandises sont ouverts et que les marchandises sont exposées. Et https est un camion porte-conteneurs fermé, ce qui améliore naturellement beaucoup la sécurité.

HTTPS est plus sécurisé que HTTP et plus convivial pour les moteurs de recherche, ce qui est bénéfique pour le référencement. Google et Baidu préfèrent indexer les pages Web HTTPS ;

HTTPS nécessite un certificat SSL, mais HTTP le fait. non ;

Port standard HTTPS 443, port standard HTTP 80;

HTTPS est basé sur la couche de transport, HTTP est basé sur la couche d'application;

HTTPS affiche un vert verrou de sécurité dans le navigateur, HTTP ne le fait pas ;

6. Pourquoi tous les sites Web n'utilisent-ils pas HTTPS

Puisque HTTPS est si sûr et fiable, pourquoi ne pas l'utiliser. tous les sites Web utilisent HTTPS ?

Tout d'abord, beaucoup de gens pensent encore qu'il existe un seuil pour la mise en œuvre du HTTPS. Ce seuil réside dans la nécessité d'un certificat SSL délivré par une autorité de certification faisant autorité. De la sélection des certificats, de l'achat au déploiement, le modèle traditionnel prend plus de temps et demande plus de main d'œuvre.

Deuxièmement, on pense généralement que HTTPS consomme plus de performances que HTTP, car la communication cryptée consomme plus de ressources CPU et mémoire que la communication en texte brut. Si chaque communication est cryptée, elle consommera beaucoup de ressources, et lorsqu'elle est répartie sur un seul ordinateur, le nombre de requêtes pouvant être traitées sera inévitablement réduit. Mais ce n'est pas le cas. Les utilisateurs peuvent résoudre ce problème en optimisant les performances et en déployant des certificats dans SLB ou CDN. Pour donner un exemple pratique, pendant la période « Double Eleven », Taobao et Tmall utilisant HTTPS pour l'ensemble du site assuraient toujours un accès, une navigation, des transactions et autres opérations fluides sur le site Web et les terminaux mobiles. Grâce à des tests, il a été constaté que les performances de nombreuses pages optimisées sont les mêmes que celles de HTTP, voire légèrement améliorées, de sorte que HTTPS n'est en réalité pas plus lent après l'optimisation.

De plus, vouloir économiser sur le coût d'achat des certificats est également une des raisons. Pour la communication HTTPS, les certificats sont indispensables. Le certificat utilisé doit être acheté auprès d'une autorité de certification (CA).

La dernière chose est la sensibilisation à la sécurité. Par rapport à la Chine, la sensibilisation à la sécurité et l'application technologique de l'industrie Internet étrangère sont relativement matures, et la tendance au déploiement du HTTPS est promue conjointement par la société, les entreprises et les gouvernements.

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!