Maison >Problème commun >Quel est le principe de la communication HTTPS ?

Quel est le principe de la communication HTTPS ?

藏色散人
藏色散人original
2020-07-02 09:03:404378parcourir

Le principe de communication de HTTPS est le suivant : HTTPS est "HTTP sur SSL/TLS". Par rapport à HTTP, HTTPS a une couche supplémentaire de "SSL/TLS". HTTPS nécessite un échange entre le client et le serveur avant. transmission de données. Au cours du processus de prise de contact, les informations cryptographiques utilisées par les deux parties pour crypter les données transmises seront établies.

Quel est le principe de la communication HTTPS ?

Introduction :

Protocole HTTP (HyperText Transfer Protocol, Hypertext Transfer Protocol) : Le client est-il Protocole de communication de couche application entre un navigateur ou un autre programme et un serveur Web. HTTPS (nom complet : HyperText Transfer Protocol over Secure Socket Layer) peut être compris comme HTTP+SSL/TLS, c'est-à-dire qu'une couche SSL est ajoutée à HTTPS. La base de sécurité de HTTPS est SSL, donc les détails du cryptage nécessitent SSL pour. HTTP sécurisé.

La différence entre HTTPS et HTTP :

a Le protocole https vous oblige à demander un certificat auprès de CA. Généralement, il existe. quelques certificats gratuits et vous devez payer des frais.

b. http est un protocole de transfert hypertexte, et les informations sont transmises en texte brut ; https est un protocole de transmission sécurisé et crypté SSL.

c. http et https utilisent des méthodes de connexion complètement différentes et utilisent des ports différents. Le premier est 80 et le second est 443.

d. La connexion http est très simple et sans état ; le protocole HTTPS est un protocole réseau construit à partir du protocole SSL+HTTP qui peut effectuer une transmission cryptée et une authentification d'identité, et est plus sécurisé. que le protocole http.

Le rôle du HTTPS

Son rôle principal peut être divisé en deux types : l'un est d'établir un canal de sécurité de l'information pour assurer la transmission des données la sécurité ; l’autre est de confirmer l’authenticité du site Web.

 a. Au sens général, https signifie que le serveur dispose d'un certificat. L'objectif principal est de garantir que le serveur est bien le serveur qu'il prétend être. C'est la même chose que le premier point ; toutes les communications entre le serveur et le client sont cryptées.

b. Plus précisément, le client génère une clé symétrique et échange la clé via le certificat du serveur, ce qui est un processus de prise de contact au sens général. Cette partie sera présentée en détail ci-dessous.

  c. Tous les échanges d'informations ultérieurs seront cryptés. Même si un tiers l’intercepte, cela n’a aucun sens car il n’a pas la clé, et bien sûr cela ne sert à rien de la falsifier.

 d. Dans certains cas où il existe des exigences pour le client, celui-ci doit également disposer d'un certificat.

Pourquoi le protocole HTTPS est nécessaire :

Le protocole HTTP est un protocole de transmission de texte brut non crypté si le client (APP, navigateur) l'utilise. Transmission HTTP Les données seront divulguées et le contenu de la transmission pourra être détourné par des intermédiaires pour modifier le contenu de la transmission. Comme le montre la figure ci-dessous, une communication HTTP APP typique est détournée et modifiée par l'opérateur, et des publicités sont insérées :

Afin de protéger la sécurité des informations des utilisateurs, de protéger leurs intérêts commerciaux et de réduire la surface d'attaque, nous devons assurer la sécurité des canaux de communication. utilisez HTTPS, qui est facile à développer.

Principe de communication HTTPS

HTTPS est HTTP sur SSL/TLS, HTTP est le protocole de la couche application, TCP est le protocole de la couche transport, entre la couche application et le transport couche, Ajout d'une couche de socket sécurisée SSL/TLS :

Comme le montre la figure ci-dessus, HTTPS a une couche supplémentaire De SSL par rapport à HTTP/TLS, la couche SSL/TLS est responsable de la négociation des algorithmes de cryptage et de déchiffrement, de l'échange de clés et de l'établissement des connexions de communication entre le client et le serveur.

HTTPS nécessite une prise de contact entre le client (navigateur) et le serveur (site Web) avant de transmettre les données. Au cours du processus de prise de contact, les informations de mot de passe permettant aux deux parties de crypter les données transmises seront. établi. Le protocole TLS/SSL n'est pas seulement un ensemble de protocoles de transmission cryptés, mais aussi une œuvre d'art soigneusement conçue par un artiste utilisant le cryptage asymétrique, le cryptage symétrique et les algorithmes HASH. Le processus de prise de contact est le suivant :

(1).client_hello

Le client initie une demande et transmet les informations de la demande en texte clair, y compris les informations de version et la suite de chiffrement, la liste des candidats pour l'algorithme de compression, les nombres aléatoires, les champs d'extension et d'autres informations, les informations pertinentes sont les suivantes :

• La version du protocole TSL la plus prise en charge. , de bas en haut, SSLv2 SSLv3 TLSv1 TLSv1 .1 TLSv1.2, les versions inférieures à TLSv1 ne sont fondamentalement plus utilisées

• Liste des suites de chiffrement prises en charge par le client, chaque chiffrement ; la suite correspond au principe TLS précédent Une combinaison de quatre fonctions : algorithme d'authentification Au (vérification d'identité), algorithme d'échange de clés KeyExchange (négociation de clé), algorithme de cryptage symétrique Enc (cryptage des informations) et résumé des informations Mac (vérification de l'intégrité ) ;

• Liste des méthodes de compression prises en charge, utilisées pour la compression et la transmission ultérieures des informations

• Nombre aléatoire random_C, utilisé pour la génération de clé ultérieure ;

• Extensions de champ d'extension, prenant en charge les paramètres pertinents des protocoles et des algorithmes et d'autres informations auxiliaires, etc. Le SNI commun est un champ d'extension, et le rôle de ce champ sera discuté séparément plus tard.

(2).server_hello+server_certificate+sever_hello_done

• server_hello, le serveur renvoie les résultats des informations de négociation, y compris la version du protocole sélectionnée pour utiliser la version, la suite de chiffrement sélectionnée, la méthode de compression de l'algorithme de compression sélectionnée, le nombre aléatoire random_S, etc., où le nombre aléatoire est utilisé pour la négociation de clé ultérieure

• server_certificates, server- ; configuration latérale Chaîne de certificat correspondante, utilisée pour la vérification de l'identité et l'échange de clés

• server_hello_done, informe le client que les informations server_hello ont été envoyées

( 3).Vérification du certificat

Le client vérifie la validité du certificat Si la vérification est réussie, une communication ultérieure sera effectuée. Sinon, des invites et des opérations seront effectuées. selon différentes conditions d'erreur. La vérification de la légalité comprend les éléments suivants :

• Chemin de certificat de confiance de [chaîne de certificats], la méthode est celle mentionnée ci-dessus ;

• Que le certificat soit révoqué ou non, il existe deux méthodes : CRL hors ligne et OCSP en ligne. Différents clients se comporteront différemment ;

• Date de validité, que ce soit le. le certificat est dans la plage de temps valide ;

• Domaine du nom de domaine, vérifiez si le nom de domaine du certificat correspond au nom de domaine d'accès actuel et analyse ultérieure des règles de correspondance

(4 ).client_key_exchange+change_cipher_spec+encrypted_handshake_message

(a) client_key_exchange, une fois la vérification de validité réussie, le client calcule et génère un nombre aléatoire pré- master, le crypte avec la clé publique du certificat, et l'envoie au serveur

(b) A ce moment, le client a obtenu toutes les informations nécessaires au calcul de la clé de négociation : deux nombres aléatoires en clair random_C et random_S et le pré-maître généré par sa propre clé de négociation ;

enc_key=Fuc(random_C, random_S, Pre-Master)

(c) change_cipher_spec, le client informe le serveur pour le suivi Toutes les communications utilisent des clés de communication négociées et des algorithmes de cryptage pour les communications cryptées

(d) approved_handshake_message ; , combine les valeurs de hachage de tous les paramètres de communication précédents et d'autres informations associées pour générer une donnée, en utilisant le secret de session de clé négociée qui est crypté avec l'algorithme puis envoyé au serveur pour vérification des données et de la poignée de main

(5).change_cipher_spec+encrypted_handshake_message

(a) Le serveur déchiffre les données pré-maîtres cryptées avec la clé privée et calcule la clé de négociation en fonction sur les deux nombres aléatoires en clair random_C et random_S précédemment échangés : enc_key=Fuc(random_C, random_S, Pre-Master);

(b) Calculer la valeur de hachage de tous les messages précédemment reçus, puis déchiffrez le message chiffré_handshake_message envoyé par le client, vérifiez l'exactitude des données et de la clé ;

(c) change_cipher_spec, une fois la vérification réussie, le serveur envoie également change_cipher_spec pour informer le client que les communications ultérieures utiliseront la clé et l'algorithme négociés pour la communication cryptée ;

(d) approved_handshake_message, Le serveur combine également toutes les informations sur les paramètres de communication actuels pour générer une donnée, la crypte en utilisant la clé négociée enc_key et l'algorithme et l'envoie au client

(6) La poignée de main se termine

Le client calcule la valeur de hachage. de tous les messages reçus, utilise la clé négociée pour déchiffrer le message_handshake_crypté et vérifie les données et la clé envoyées par le serveur. Si la vérification réussit, la poignée de main est terminée

(7). ). Communication cryptée

Commencez à utiliser des clés et des algorithmes négociés pour la communication cryptée

. Le chronogramme est le suivant :

Certificat de vérification

Dans (3) vérification du certificat, le client vérifiera le certificat envoyé par le serveur. Examinons le processus en détail ci-dessous. le travail a été effectué

1. Vérifiez l'émetteur et la période de validité

2. Vérifiez s'il figure dans la liste de confiance

. 🎜>

2. Vérifier la légalité

Lors de la vérification du certificat, le client lit les informations en clair pertinentes dans le certificat et utilise la même fonction de hachage pour calculer les informations. condensez, puis utilisez la clé publique de l'autorité de certification correspondante (récupérée localement) pour déchiffrer les données de signature et comparer les informations condensées du certificat. Si elles sont cohérentes, la légitimité du certificat peut être confirmée, c'est-à-dire. la clé publique est légitime ;

Contenu du certificat :

Clé publique du demandeur, informations organisationnelles et informations personnelles du demandeur, informations CA de l'autorité émettrice, validité l'heure, le numéro de série du certificat et d'autres informations en texte brut, en même temps Contient une signature

Génération de signature : utilisez une fonction de hachage pour calculer le résumé des informations publiques en texte clair, puis utilisez la clé privée de l'autorité de certification pour chiffrer le résumé des informations, et le texte chiffré est la signature .
 


Conseils ;

1. Le Client utilise la clé publique envoyée par le Serveur pour crypter les données, et envoie les données cryptées au Serveur. Le Serveur utilise la clé privée pour décrypter, ce qui est un cryptage asymétrique2. Lorsque le client et le serveur maîtrisent la clé de négociation

enc_key, les deux parties utilisent la clé pour chiffrer et déchiffrer, ce qui est un chiffrement symétrique

Présentation des algorithmes de chiffrement

L'implémentation des fonctions de TLS/SSL repose principalement sur trois types d'algorithmes de base : la fonction de hachage Hash, le chiffrement symétrique et le chiffrement asymétrique, qui utilise cryptage asymétrique pour réaliser l'authentification d'identité et la négociation de clé, l'algorithme de cryptage symétrique utilise la clé négociée pour crypter les données et vérifie l'intégrité des informations en fonction de la fonction de hachage.


1. Cryptage symétrique

Il en existe deux types : streaming et regroupement. La même clé est utilisée pour le cryptage et le déchiffrement.

Par exemple : DES, AES-GCM, ChaCha20-Poly1305, etc.

2. Chiffrement asymétrique

La clé utilisée pour le chiffrement et la clé utilisée pour le déchiffrement sont différentes, respectivement appelées : clé publique, clé privée, clé publique La clé et L'algorithme est public et la clé privée est gardée secrète. Les algorithmes de chiffrement asymétriques ont de faibles performances, mais sont hautement sécurisés. En raison de leurs caractéristiques de chiffrement, la longueur des données pouvant être chiffrées par les algorithmes de chiffrement asymétriques est également limitée.

Par exemple : RSA, DSA, ECDSA, DH, ECDHE

Algorithme de hachage

Convertissez des informations de longueur arbitraire en une valeur de longueur fixe plus courte, généralement sa longueur est beaucoup plus petite que les informations et l'algorithme est irréversible.

Par exemple : MD5, SHA-1, SHA-2, SHA-256, etc.

Signature numérique

Une signature consiste à ajouter un élément de contenu (la valeur de l'information après hachage) après l'information, ce qui peut prouver que l'information n'a pas été modifiée. La valeur de hachage est généralement cryptée (c'est-à-dire signée), puis envoyée avec le message pour garantir que la valeur de hachage n'est pas modifiée.

Authentification bidirectionnelle :

Le serveur peut également demander à vérifier le client, c'est-à-dire une authentification bidirectionnelle. envoyer les informations client_certificate_request dans le processus 2. Dans le processus 4, les informations client_certificate et certificate_verify_message sont envoyées en premier.La méthode de vérification du certificat est fondamentalement la même.Le certificate_verify_message est une donnée basée sur les informations de communication négociées cryptées avec la clé privée du client. Le serveur peut utiliser la clé publique correspondante pour la décrypter et la vérifier.

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!

Déclaration:
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