How does browser generate symmetric key during SSL handshake

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”.

Quoting from a this great video on network video, minute 1:18:07

Well where do you get randomness on your computer because your computer is a deterministic device?

Well it collects entropies like your mouse stroke movements, your key stroke movements and the timing of your hard disk, it tries to collect all that randomness from the universe into a pull so that it can generate random keys just for one connection [this session]. And if that randomness is broken and its happened many times in the last 30 years, then none of this works. If the adversary can figure what your randomness can be then they can guess your keys. So use good randomness.

Note: the keys are created per session.