Perché TLS non firma ciphersuite?

Question

Perché TLS non firma ciphersuite?

#1 da (2 voti)

1

TLS negozia una versione ciphersuite e TLS da utilizzare durante l'handshake. Conferma che la stretta di mano non è stata manomessa e la versione di ciphersuite e TLS non è stata sottoposta a downgrade utilizzando le crittografie negoziate, come spiegato qui . Tuttavia, questa verifica si basa sui cifrari negoziati sull'handshake, quindi se i cifrari scelti dall'attaccante fossero sufficientemente deboli da rompersi rapidamente, potrebbe essere in grado di inviare anche questi messaggi di conferma.

La mia domanda è, perché il server non usa la sua chiave privata per firmare la sua versione ciphersuite e TLS (e timestamp di validUntil) in modo che il client possa rilevare gli attacchi di downgrade? Mentre il client non ha la chiave pubblica al momento, la firma può essere mantenuta dal client fino a quando il certificato non viene convalidato e quindi verificato. Perché questo non viene fatto dal protocollo TLS?

tls tls-downgrade

posta Peter Harmann 27.04.2018 - 13:53

fonte

1 risposta

Leggi altre domande sui tag tls tls-downgrade

In che modo le app iOS 11 mi identificano nonostante la reinstallazione dell'app? Come proteggere lo Shadow Stack?

score 2 · Answer 1

Il server firma la ciphersuite. L'intero protocollo di negoziazione (che copre la ciphersuite, le chiavi, ecc.) È firmato. Questa è l'ultima cosa nell'handshake: il messaggio Finished . Vedi Cosa impedisce a un utente malintenzionato di manomettere i dati inviati durante l'handshake SSL / TLS? e Come funziona SSL / TLS? per ulteriori dettagli.

Nota:

this verification relies on the ciphers negotiated on the handshake, so if the ciphers the attacker chosen were sufficiently weak to break quickly, he may be able to send these confirmation messages as well.

e chiedi:

why doesn't the server use its private key to sign its ciphersuite and TLS version (and timestamp of validUntil) so the client can detect downgrade attacks?

Ancora una volta, il server fa usa la sua chiave privata per firmare la ciphersuite e il client la la verifica. Succede alla fine della stretta di mano perché non può accadere fino a quando il client e il server non hanno concordato su quale sia la chiave del server e perché dovrebbe essere considerata attendibile.

Sei preoccupato per un utente malintenzionato che convince il cliente a utilizzare una cipheruite debole per la quale è possibile falsificare una firma. Bene, ci sono due casi.

Il client sa che la ciphersuite è debole e si rifiuta di usarla. Quindi non c'è nessun problema. Il client chiuderà la connessione.
Il client non sa che la ciphersuite è debole. Quindi non c'è niente da fare. L'intera conversazione avviene con l'attaccante. Il server legittimo non è affatto coinvolto. Il server legittimo non può in alcun modo proteggere il client da un attacco quando il server legittimo non partecipa nemmeno al protocollo.