How exactly is this protecting against a malicious DNS routing?
Assolutamente no.
Se un malvagio ha un certificato valido (ad esempio da un hacking di una CA) e poi riesce a man-in-the-middle, allora la tua connessione viene violato.
I was expecting a challenge response using the public key of the server, but I cannot find it.
Per fare ciò dovresti prima sapere alcune cose sul server. E di solito non hai queste informazioni. Ma il blocco dei certificati è un modo di comunicare le informazioni:
Il blocco dei certificati aiuta
Il blocco dei certificati consente di fornire a un cliente alcune informazioni aggiuntive sui certificati. Ad esempio: "Per i miei certificati, accetta solo le firme di ACME-CA." Oppure "Per i miei certificati, accettali solo se contengono le seguenti chiavi pubbliche ...".
Ulteriori letture per bloccare: Wikipedia: Inserimento di chiavi pubbliche HTTP
MODIFICA: come vengono autenticati gli scambi di chiavi?
Dalla sezione dei commenti:
I am exactly asking how the server proves that he has the private part. It should be a challenge/response initiated by the client using the public key of the server (or using the symmetric key once it is established). I cannot find this in the texts
In effetti, qui c'è una sfida / una risposta.
Questo è dettagliato in una sottosezione della RFC TLS 1.2.
Ci sono tre opzioni:
-
F.1.1.1. Scambio chiave anonimo
Nessuna autenticazione.
-
F.1.1.2. Scambio e autenticazione delle chiavi RSA
Il client crittografa (parte) la chiave di sessione di crittografia di massa con la chiave pubblica del server. La capacità del server di decodificare è la prova del possesso della chiave privata.
No "Segretezza in avanti":
Se la chiave privata del server è MAI esposta, anche se con anni di ritardo, tutte le vecchie chiavi di sessione possono essere decifrate retroattivamente.
-
F.1.1.3. Scambio chiave Diffie-Hellman con autenticazione
Client e server utilizzano un protocollo di accordi chiave diverso. Il server firma quindi la trascrizione delle negoziazioni con la sua chiave privata. Se il client può verificare questa firma con la chiave pubblica del server, allora è la prova che il server conosce davvero la chiave privata.
Ha "Segretezza in avanti":
Il vantaggio di questa procedura è "Inoltra segretezza". Se la chiave privata del server viene mai esposta anni dopo, le chiavi di sessione NON possono essere decifrate retroattivamente. (Perché, beh, non sono mai stati crittografati con la chiave privata del server in primo luogo. Vedi chiave Diffie-Hellman scambiare per i dettagli.)