ECDHE_RSA e gmail

5

Sto usando Chrome su Ubuntu Linux per connettermi a Gmail. Le informazioni di connessione dicono che ECDHE_RSA è usato per lo scambio di chiavi simmetriche https.

In base alla mia comprensione di TLS e Gmail, il mio cliente crea una chiave simmetrica, crittografa con la chiave pubblica di Google elencata nel suo certificato e quindi invia a Google. Dal momento che il mio browser riconosce il certificato di Google, è sicuro presumere che la mia connessione sia sicura e non possa essere compromessa da un uomo nel mezzo dell'attacco? In che modo un uomo nel mezzo potrebbe mai visualizzare la chiave simmetrica poiché non ha la chiave privata di Google per decodificare il messaggio?

Non ho un certificato importato nel mio browser. Ho usato Wireshark per curiosare la negoziazione TLS. Vedo nel mio pacchetto "client hello" invio informazioni su quali suite di crittografia supporta il mio client, un numero casuale e informazioni sulla curva ellittica. Dopo che il server di Gmail risponde con un "server hello" e "certificato, scambio di chiavi del server, server ciao fatto", il mio client invia quindi "scambio di chiavi client, modifica specifica cipher, messaggio crittografato di handshake". È giusto presumere che la chiave simmetrica crittografata con la chiave pubblica di Google sia contenuta in questo pacchetto sotto il "messaggio di handshake crittografato" (TLSv1.1 Record Layer: Protocollo Handshake: messaggio crittografato dell'handshake).

C'è un modo in cui un server potrebbe impronte digitali (cioè identificare in modo univoco) il mio cliente in una futura connessione TCP su una rete diversa tramite la chiave simmetrica che il mio cliente ha generato sopra?

    
posta Randall 07.03.2013 - 10:51
fonte

1 risposta

3

Con ECDHE_RSA, lo scambio di chiave attuale utilizza curva ellittica Diffie-Hellman ; la chiave pubblica ECDH del server non è nel suo certificato, ma nel messaggio ServerKeyExchange , che il server firma con la sua chiave privata (e il tuo browser verifica quella firma relativamente alla chiave pubblica che è nel certificato del server). La chiave simmetrica risultante da ECDH non è "scelta" dal solo client, ma è comunque una chiave condivisa da client e server e nient'altro. È meno diretto della tua descrizione, ma la tua idea è corretta: infatti, a patto che l'implementazione sia corretta e il tuo browser convalidi correttamente il certificato del server, i dati scambiati saranno al sicuro da intercettazioni, imitazioni e alterazioni dannose.

Se il client tenta di riconnettersi allo stesso server (questo è normale in un contesto Web, poiché i server tendono a rilasciare le connessioni dopo 15 secondi di inattività), tenterà di riutilizzare la chiave simmetrica da ECDH, in modo da evitare l'intera attività di crittografia asimmetrica e, soprattutto, per evitare un roundtrip di rete. Questa è la stretta di mano abbreviata di SSL / TLS . Se il client e il server ricordano ancora la connessione precedente (chiamata "sessione SSL"), funzionerà. In queste condizioni , il server potrebbe potenzialmente riconoscere il client come "lo stesso di prima".

Tuttavia, i parametri della sessione SSL (la chiave simmetrica negoziata) non sono memorizzati in un'area di memoria permanente e sono soggetti a dimenticanza. Se chiudi il browser, dimenticherà tutte queste sessioni. Per impostazione predefinita, un server Apache memorizzerà i parametri della sessione SSL per 5 minuti , o eventualmente meno se gestisce molte connessioni (dal momento che il suo spazio di archiviazione per tali parametri ha una dimensione configurabile ma finita).

Vedi questa risposta per una descrizione dettagliata del Protocollo SSL.

    
risposta data 07.03.2013 - 13:14
fonte

Leggi altre domande sui tag