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:
- Il client invia la sua chiave pubblica
- 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:
-
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?
-
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?
-
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?