Comment navigateur génération de clé symétrique durant la négociation SSL

Question

J'ai une petite confusion sur handshake SSL entre le navigateur et le serveur dans un scénario web typique https:

Ce que j'ai compris à ce jour est que dans le processus de poignée de main SSL, client (navigateur dans ce cas) crypte une clé symétrique sélectionnée aléatoirement avec la clé publique (certificat reçu du serveur). Ceci est renvoyé au serveur, le serveur décrypte (clé symétrique) avec la clé privée. Cette clé symétrique est maintenant utilisée pendant le reste de la session pour chiffrer/déchiffrer les messages aux deux extrémités. L'une des principales raisons de le faire est donnée par un cryptage plus rapide utilisant des clés symétriques.

Questions 1) Comment le navigateur choisit-il et génère-t-il cette clé symétrique «choisie au hasard»?

2) Les développeurs (ou/et les utilisateurs du navigateur) ont-ils le contrôle sur ce mécanisme de génération de clés symétriques?

Answer 1

Here est une très bonne description du fonctionnement de l'établissement de connexion HTTPS. Je fournirai résumé comment la clé de session est acquise par les deux parties (client et serveur), ce processus est connu comme « un protocole d'accord de clé », voici comment cela fonctionne:

1. Le client génère 48 octets « pré secret maître "valeur aléatoire.
2. Le client remplit ces octets avec des données aléatoires pour que l'entrée soit égale à 128 octets.
3. Le client le crypte avec la clé publique du serveur et l'envoie au serveur.

4. Ensuite, la clé principale est produit par les deux parties de manière suivante:

   master_secret = PRF(
       pre_master_secret, 
       "master secret", 
       ClientHello.random + ServerHello.random 
   ) 
   

Le PRF est le « pseudo-aléatoire Fonction » qui est également défini dans les spécifications et est très intelligent. Il combine le secret, l'étiquette ASCII, et les données de départ que nous lui donnons en utilisant le hachage Message versions du code d'authentification (HMAC) des fonctions de hachage MD5 et SHA-1 . La moitié de l'entrée est envoyée à chaque fonction de hachage. C'est intelligent parce qu'il est assez résistant à l'attaque, même face à des faiblesses dans MD5 et SHA-1. Ce processus peut faire des commentaires sur lui-même et itérer pour toujours pour générer autant d'octets que nécessaire. En suivant cette procédure, nous obtenons un "secret principal" de 48 octets.