Il TLS funziona correttamente?
Usando Facebook come ad es. qui - fb.com
- La CA ha il proprio pub e pvt.
- CA fornisce il tasto fb a pub e pvt
- Tutti i browser hanno già la chiave di pubblicazione CA - il certificato di base.
- Quando ti connetti a fb.com. Fb manda la loro chiave di pub a me crittografata con il tasto pvt di CA
- Il mio browser la decrittografa con la chiave di pubblicazione CA già esistente.
- Ora ho la chiave fb pub e il mio browser genera una chiave di sessione che viene inviata a fb crittografata con la chiave di pubblicazione fb
- E quindi fb.com e il mio browser hanno entrambi la sessione per iniziare a utilizzare una crittografia simmetrica come AES.
Non capisco la parte in cui fb è in grado di crittografare la propria chiave di pub con la chiave pvt di CA.
Come può avere accesso alla chiave pvt CA? O è già stato firmato dalla CA la prima volta che viene consegnato a fb?
Ora sta ottenendo la chiave di sessione
Ecco le 2 risposte più votate da Come è possibile che le persone che osservano una connessione HTTPS stabilita non sappiano come decrittografarla?
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.
Diciamo x^3 mod n = Z
I dubbi qui sono che se il Z può essere scambiato allora quando è usato il meccanismo nella citazione sottostante, di crittografare la chiave di sessione con la chiave pubblica del server?
Inoltre, perché l'attaccante non può calcolare x dalla formula x^3 mod n = Z , poiché l'autore dell'attacco ha n quando il server lo ha inviato al client e ha anche Z quando il client lo ha restituito?
E la seconda risposta da lì:
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.