Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How does browser generate symmetric key during SSL handshake

Tags:

I have a small confusion on SSL handshake between browser and server in a typical https web scenario:

What I have understood so far is that in the process of SSL handshake, client (browser in this case) encrypts a randomly selected symmetric key with the public key (certificate received from server). This is sent back to the server, server decrypts it (symmetric key) with the private key. This symmetric key is now used during rest of the session to encrypt/decrypt the messages at both the ends. One of main reasons to do so is given as faster encryption using symmetric keys.

Questions

1) How does browser pick and generates this "randomly" selected symmetric key?

2) Do developers (or/and browser users) have control on this mechanism of generating symmetric keys?

like image 265
sanjeev Avatar asked Oct 14 '10 17:10

sanjeev


People also ask

How is symmetric key generated in TLS?

TLS uses both asymmetric encryption and symmetric encryption. During a TLS handshake, the client and server agree upon new keys to use for symmetric encryption, called "session keys." Each new communication session will start with a new TLS handshake and use new session keys.

How is symmetric key shared in TLS?

TLS uses symmetric-key encryption to provide confidentiality to the data that it transmits. Unlike public-key encryption, just one key is used in both the encryption and decryption processes. Once data has been encrypted with an algorithm, it will appear as a jumble of ciphertext.


1 Answers

Here is a very good description of how HTTPS connection establishment works. I will provide summary how session key is acquired by both parties (client and server), this process is known as "a key agreement protocol", here how it works:

  1. The client generates the 48 byte “pre-master secret” random value.
  2. The client pads these bytes with random data to make the input equal to 128 bytes.
  3. The client encrypts it with server's public key and sends it to the server.
  4. Then master key is produced by both parties in following manner:

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

The PRF is the “Pseudo-Random Function” that’s also defined in the spec and is quite clever. It combines the secret, the ASCII label, and the seed data we give it by using the keyed-Hash Message Authentication Code (HMAC) versions of both MD5 and SHA-1 hash functions. Half of the input is sent to each hash function. It’s clever because it is quite resistant to attack, even in the face of weaknesses in MD5 and SHA-1. This process can feedback on itself and iterate forever to generate as many bytes as we need.

Following this procedure, we obtain a 48 byte “master secret”.

like image 145
Andrey Avatar answered Sep 21 '22 21:09

Andrey