is the public key sent by server encrypted or clear? I assume it is clear since it is public
La chiave pubblica del server è contenuta in chiaro nel certificato del server che viene inviato in chiaro dal server, il che significa che anche la chiave pubblica viene inviata in modo implicito. Si noti che questo è il caso solo con l'autenticazione del server basata su certificato, che è il modo più comune per autenticare il server in TLS ma non l'unico. Altri modi per autenticare il server sono ad esempio le chiavi pre-condivise (PSK) in cui non sono coinvolte chiavi pubbliche.
How are the session key and public key related?
Il risultato dello scambio di chiavi è un segreto pre-master che viene poi utilizzato per derivare un master secret che viene poi utilizzato per derivare le chiavi di sessione, ovvero le chiavi per crittografare e proteggere (HMAC) i dati dell'applicazione.
Se lo scambio di chiavi Diffie-Hellman viene usato come dichiari, non esiste alcuna relazione tra la chiave pubblica e il segreto pre-master e quindi non tra la chiave pubblica e le chiavi di sessione. L'unico uso del certificato in questo caso è quello di autenticare il server e non svolge alcun ruolo nello scambio di chiavi. Lo scambio di chiavi Diffie-Hellman può anche essere utilizzato per gli handshake TLS in cui non è coinvolta alcuna chiave pubblica, ad esempio con l'autenticazione PSK.
Does the client sends session key to the server? session key sent: f(Random_gen_number, Public_key) where f is an encryption function?
Con lo scambio di chiavi Diffie-Hellman non c'è nulla di simile a questo. Con lo scambio di chiavi RSA il client crea invece il segreto pre-master completamente sul lato client (cioè non è il risultato di uno scambio di chiavi in cui entrambe le parti sono coinvolte, come nello scambio di chiavi DH) e lo invia al server crittografato con il chiave pubblica del server. Il server quindi decrittografa con la sua chiave privata (segreta) e quindi può estrarre il segreto pre-master. Il processo di derivare il segreto principale e le chiavi di sessione da questo è quindi lo stesso che con lo scambio di chiavi DH.
Questo processo di invio del segreto pre-master al server significa anche che la conoscenza della chiave privata del server consente di recuperare il segreto pre-master, derivare le chiavi di sessione e decrittografare tutto il traffico. Questo è vero anche per il traffico più vecchio se il traffico è stato catturato in un determinato momento e l'hacker o il servizio segreto ha avuto accesso alla chiave privata solo successivamente. Contrariamente a ciò, con lo scambio di chiavi DH non avviene alcuno scambio effettivo del segreto pre-master, ma è invece derivato da entrambi i lati. Avere accesso alla chiave privata del server non consentirà a un utente malintenzionato di decodificare il traffico sniffato, ovvero è necessario un attacco man-in-the-middle attivo e in tempo reale. Ecco perché lo scambio di chiavi DH è quello preferito oggi e l'unico supporto a partire da TLS 1.3.