Perché l'handshake SSL non può essere eseguito in un solo passaggio?

5

Sono sicuro che ci sono molte ovvie ragioni per questo, ma perché non è possibile avviare una sessione SSL con un round-trip?

Sembra che questo sarebbe sufficiente:

  1. Il client invia la sua chiave pubblica
  2. Il server risponde con:
    • Il suo certificato (chiave pubblica + tutto ciò che è necessario per verificarlo)
    • Una chiave simmetrica da utilizzare (crittografata con la chiave pubblica del client / firmata con la chiave privata del server)

I problemi a cui riesco a pensare sono:

  1. Potrebbe essere necessario conoscere in anticipo la versione del protocollo.

    • Sembra che il protocollo possa essere progettato in modo che il client prima mandi una versione, poi la sua chiave pubblica, e se il server non la capisce, invia un messaggio "prova questa versione", che sarebbe più veloce nel migliore dei casi (client e server capiscono entrambi lo stesso protocollo), e altrettanto veloci come SSL nel peggiore dei casi ("versione 2 ... la mia chiave pubblica", "Non capisco, usa la versione 1", " versione 1 ... la mia chiave pubblica "," il mio certificato ... chiave crittografata).
    • Per rendere il protocollo più compatibile con le versioni precedenti, potresti avere due versioni, una per le chiavi pubbliche da scambiare e l'altra per tutto il resto. Solo la versione a chiave pubblica potrebbe interrompere la compatibilità e richiedere il secondo round-trip.
    • Ovviamente questo non sarebbe retrocompatibile con SSL ora, ma perché non era lì in primo luogo?
  2. Forse più lavoro per il server, dal momento che è necessario (1) generare una chiave simmetrica crittograficamente protetta, (2) crittografare quella chiave utilizzando la crittografia a chiave pubblica, (3) firmare il risultato utilizzando la crittografia a chiave pubblica . Il problema è che sarebbe troppo facile sovraccaricare il server?

  3. Qualcosa che mi manca?

Questo mi ha sempre infastidito tutto il giorno, dal momento che sembra così ovvio, ma ci deve essere qualche difetto evidente che mi manca (ed è per questo che non sono un ricercatore di sicurezza).

EDIT:

Un link pubblicato da @lour ha questa citazione:

In a TLS handshake, the "Finished" messages serve to validate the entire handshake. These messages are based on a hash of the handshake so far processed by a PRF keyed with the new master secret (serving as a MAC), and are also sent under the new Cipher Spec with its keyed MAC, where the MAC key again is derived from the master secret. The protocol design relies on the assumption that any server and/or client authentication done during the handshake carries over to this. While an attacker could, for example, have changed the cipher suite list sent by the client to the server and thus influenced cipher suite selection (presumably towards a less secure choice) or could have made other modifications to handshake messages in transmission, the attacker would not be able to round off the modified handshake with a valid "Finished" message: every TLS cipher suite is presumed to key the PRF appropriately to ensure unforgeability. Once the handshake has been validated by verifying the "Finished" messages, this confirms that the handshake has not been tampered with, thus bootstrapping secure encryption (using algorithms as negotiated) from secure authentication.

Quindi perché non solo il server e il client firmano entrambi i loro messaggi di cifratura con le loro chiavi private? Lo so, più lavoro, ma ancora più veloce di un RTT, giusto?

    
posta Brendan Long 21.09.2011 - 04:49
fonte

3 risposte

15

Se comprendo correttamente la tua proposta, ci sono almeno due vulnerabilità:

Riproduci attacco

Un utente malintenzionato potrebbe essere in grado di annusare una comunicazione crittografata, registrarla e riprodurla in un secondo momento.

Esistono due approcci comuni per prevenirlo: utilizzo di indicatori di data e ora, che funzionano solo in un ambiente controllato in cui è possibile essere sicuri che gli orologi siano sincronizzati. Pertanto, l'approccio comune Per evitare ciò, entrambe le parti devono inviare un numero casuale e richiedere all'altra parte di dimostrare che ha ottenuto questo numero, inviandolo o utilizzandolo in qualche operazione matematica.

Uomo nell'attacco centrale

Il browser invia la sua chiave pubblica a un utente malintenzionato. L'utente malintenzionato contatta il server reale e invia la propria chiave pubblica.

Il server risponde con il suo certificato e la chiave di sessione sia firmata con la chiave privata del server sia crittografata con la chiave pubblica dell'aggressore.

L'utente malintenzionato decodifica le informazioni e le re-crittografa con la chiave pubblica del client. La firma rimane valida perché l'utente malintenzionato non modifica il certificato o la chiave di sessione. Memorizza la chiave di sessione per un uso successivo.

Il client verifica il certificato e la firma del server reale ed è felice.

Altri approcci

Esiste un altro approccio di Google chiamato SSL False Start , che non ha questi problemi.

    
risposta data 21.09.2011 - 09:08
fonte
4

È teoricamente possibile farlo più rapidamente di quanto non sia fatto. Un sacco di motivi per cui funziona così come è dovuto alla cronologia - Netscape essenzialmente ha creato SSL da solo nel 1994, ed è stato anche in gran parte responsabile delle revisioni che sono diventate SSL 3.0 - non è stato spostato nel IETF fino a quel momento e IETF ha essenzialmente ristampato la specifica SSL 3.0 come TLS 1.0, al fine di favorire la compatibilità con le versioni precedenti. Quindi, molte decisioni sono state prese a quel punto.

Alcuni motivi per cui non può essere fatto più rapidamente sono i risultati della flessibilità inclusa nel sistema. Ad esempio, il server può decidere se richiedere o meno un certificato client all'utente e la connessione può supportare il passaggio delle cipherute in base alle esigenze. La rinegoziazione è supportata in vari casi.

Alla fine, non importa molto - la maggior parte delle implementazioni fa uso della ripresa, in cui il client specifica un ID di sessione stabilito su una nuova connessione e il server riprende da dove era stato interrotto. In pratica, i browser eseguiranno una stretta di mano completa una volta, quindi riprenderanno la sessione più e più volte. Quando lo combini con il keepalive HTTP (il solito stato di cose in HTTP / 1.1), il risultato è che non fai tante strette di mano come pensi.

Se TLS fosse stato riprogettato da zero oggi, potrebbe essere stato fatto diversamente. Tuttavia, la chattiness di TLS non è un grosso problema pratico.

    
risposta data 21.09.2011 - 15:49
fonte
2

3 . Something I'm missing?

Il problema più semplice con la tua proposta è che il server non ha modo di autenticare la chiave pubblica del client che è stata consegnata all'andata, quindi usare quella chiave per crittografare la chiave simmetrica lascia aperta la connessione a Man In The Middle.

Con il sistema attuale, i molti (client) devono cercare i pochi (server) tasti per confermare che stanno parlando con chi pensano di essere (ad es. "www.google.com"). Per invertire ciò sarebbe necessario un sistema di ricerca relativamente massiccio contro identificatori essenzialmente arbitrari e mutevoli ("dhcp123.dialup.bigisp.net").

Se stai cercando di salvare un salto, prendi una pagina da Microsoft. C'era una volta in cui IE combinava l'ACK (terza parte dell'handshake a tre vie) con il payload dei dati della richiesta HTTP in un unico pacchetto. In generale, solo i server IIS potrebbero giocare a quel gioco, naturalmente.

Non sono convinto che la distruzione di queste cose per salvare uno o due pacchetti valga la pena in ogni caso, ma è un degno gedankenexperiment.

    
risposta data 21.09.2011 - 16:39
fonte

Leggi altre domande sui tag