Chiave pubblica nel protocollo SSL

L'handshake SSL non è crittografato. Il server invia semplicemente la sua chiave pubblica nella pianura. Il client sa che può fidarsi di esso, perché è firmato da una CA totalmente degna di fiducia. Un certificato è essenzialmente una chiave pubblica con alcuni dati associati come un dominio, firmato da una CA.

Il client non deve essere in grado di decrittografare PreMasterSecret (da cui deriva la chiave di sessione), perché ha scelto il suo valore e lo ricorda ancora.

Guarda come funziona l'handshake SSL:

• Negotiation phase:
  • A client sends a ClientHello message ...
  • The server responds with a ServerHello message ...
  • The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server). This contains the public key
  • The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
  • The client responds with a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. This PreMasterSecret is encrypted using the public key of the server certificate.
  • The client and server then use the random numbers and ''PreMasterSecret'' to compute a common secret, called the "master secret". All other key data for this connection is derived from this master secret (and the client- and server-generated random values)
• The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be encrypted and authenticated
• Finally, the client sends an authenticated and encrypted Finished message, containing a hash and MAC over the previous handshake messages.
• The server will attempt to decrypt the client's Finished message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.
• Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated and encrypted
• The server sends its authenticated and encrypted '''Finished''' message.
• The client performs the same decryption and verification.

(Basato su wikipedia Secure Sockets Layer - Semplice handshake TLS )

Come puoi vedere, la crittografia è abilitata solo dopo la negoziazione e quindi il trasferimento della chiave pubblica completata.

But from where does this public key come from?

La chiave pubblica è incorporata nel certificato del server.

While generating certificates aren't we generating private key which the server use to decrypt data?

Questo è già generato prima che il certificato sia stato creato. Viene creata la coppia di chiavi, quindi un certificato scritto, una richiesta di firma del certificato viene inviata a un'autorità di certificazione e infine un certificato firmato restituito al richiedente.

How does the server reply if it has to use public key for encrypting the reply?

Il browser utilizza la chiave pubblica del server per crittografare un valore casuale da utilizzare come chiave di crittografia simmetrica. Quel valore è inviato al server. Il server risponde utilizzando un codice simmetrico.

How is the browser going to decrypt the encrypted reply from server since there is no private key at browser side?

Le risposte non sono associate a una coppia di chiavi pubblica / privata. Microsoft fa un lavoro decente nel descrivere il processo di handshake: link

La chiave pubblica del server proviene dal suo certificato . Il certificato contiene la chiave pubblica e il server lo invia al client come parte dei passaggi iniziali del protocollo. La parte difficile è non conoscere la chiave pubblica, ma accertarsi che sia quella giusta (è tutta la problematica della convalida dei certificati ).

Vedi ad esempio questa risposta e poi quella .