TLS working and the symmetric key exchange

Question

Is this TLS working correct?

Using facebook as e.g. here - fb.com

• The CA has it's own pub and pvt key.
• CA gives fb a pub and pvt key
• All browsers have the CA pub key already - the root cert.
• When you connect to fb.com. Fb sends their pub key to me encrypted with the CA pvt key
• My browser decrypts this with CA pub key it already has.
• Now i have the fb pub key and my browser generates session key which is sent to fb encrypted with fb's pub key
• And then fb.com and my browser both have session to start using a symmetric encryption like AES.

I don't get the part about fb being able to encrypt its own pub key with the CA pvt key.

How can it have access to the CA pvt key? Or is it already signed by the CA the first time it's handed over to fb?

Now getting the session key

Here's from the 2 highest rated answers from How is it possible that people observing an HTTPS connection being established wouldn't know how to decrypt it?

It is the magic of public-key cryptography. Mathematics are involved.

The asymmetric key exchange scheme which is easiest to understand is asymmetric encryption with RSA. Here is an oversimplified description:

Let n be a big integer (say 300 digits); n is chosen such that it is a product of two prime numbers of similar sizes (let's call them p and q). We will then compute things "modulo n": this means that whenever we add or multiply together two integers, we divide the result by n and we keep the remainder (which is between 0 and n-1, necessarily).

Given x, computing x3 modulo n is easy: you multiply x with x and then again with x, and then you divide by n and keep the remainder. Everybody can do that. On the other hand, given x3 modulo n, recovering x seems overly difficult (the best known methods being far too expensive for existing technology) -- unless you know p and q, in which case it becomes easy again. But computing p and q from n seems hard, too (it is the problem known as integer factorization).

So here is what the server and client do:

• The server has a n and knows the corresponding p and q (it generated them). The server sends n to the client.
• The client chooses a random x and computes x3 modulo n.
• The client sends x3 modulo n to the server.
• The server uses its knowledge of p and q to recover x.

At that point, both client and server know x. But an eavesdropper saw only n and x3 modulo n; he cannot recompute p, q and/or x from that information. So x is a shared secret between the client and the server. After that this is pretty straightforward symmetric encryption, using x as key.

Let's say x^3 mod n = Z

Doubts here are that if the Z can be exchanged then when is the mechanism in the quote below used, of encrypting the session key with the server's public key?

Also why can't the attacker figure out x from the formula x^3 mod n = Z, since the attacker has n when the server sent it to the client and also has Z when the client sent it back?

And the second answer from there:

Here's a really simplified version:

• When a client and a server negotiate HTTPS, the server sends its public key to the client.
• The client encrypts the session encryption key that it wants to use using the server's public key, and sends that encrypted data to the server.
• The server decrypts that session encryption key using its private key, and starts using it.
• The session is protected now, because only the client and the server can know the session encryption key. It was never transmitted in the clear, or in any way an attacker could decrypt, so only they know it.

Voilà, anyone can see the public key, but that doesn't allow them to decrypt the "hey-let's-encrypt-using-this-from-now-on" packet that's encrypted with that public key. Only the server can decrypt that, because only the server has that private key. Attackers could try to forge the response containing an encrypted key, but if the server sets up the session with that, the true client won't speak it because it isn't the key that the true client set.

Answer 1

In this answer I only address the main assumptions you had wrong. For more details on how TLS handshake including certificate validation and key exchange work please study How does SSL/TLS work?.

CA gives fb a pub and pvt key

No, it does not. The owner of the domain creates a key pair, puts the public part into a certificate signing request and the CA creates a certificate based on this CSR. The private key for the certificate is usually never seen by the CA although some offer to provide the key pair for the customers which of course is not recommended since the private key should be private.

When you connect to fb.com. Fb sends their pub key to me encrypted with the CA pvt key

Wrong. The server sends the certificate which contains the public key in plain. The certificate is signed by the CA. This signature is then used to build the trust chain up to the locally trusted root CA in the client. Additional chain certificates send by the server might be involved in this.

The server authenticates to the client by proving that it owns the private key matching the public key in the certificate. This is done by using the private key to sign a "challenge" which was created based on client data.

My browser decrypts this with CA pub key it already has.

Since the public key is send in plain inside the certificate there is no need to decrypt anything.

Now i have the fb pub key and my browser generates session key which is sent to fb encrypted with fb's pub key

This roughly describes the process used with RSA key exchange. With DH key exchange it is different.

I don't get the part about fb being able to encrypt its own pub key with the CA pvt key.

It does not encrypt the public key. See above.