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.
