alert crittografato con TLS handshake sul certificato client

Question

alert crittografato con TLS handshake sul certificato client

#1 da (4 voti)

2

Sto provando a eseguire il debug di un handshake TLS tra un client e un server

Client sends Hello

Server sends Hello, Certificate, Certificate request, Server hello done.

client sends Encrypted alert - content tpe Alert(21)
client sends Client key exchange
client sends Change cipher spec

server sends Change cipher spec

client sends Finished
server sends Finished

client sends Application data

Dopo questa connessione la connessione è interrotta e nei registri del server sembra che il client non abbia inviato un certificato (dove si verifica l'avviso crittografato).

Unfotunetly Non riesco a incollare i dati di wireshark mentre lavoro su una rete chiusa.

Qualsiasi aiuto sarebbe molto apprezzato!

tls

posta David Limkys 05.08.2015 - 00:15

fonte

1 risposta

Leggi altre domande sui tag tls

Impossibile caricare un file sulla pagina vulnerabile xss Qualche esempio reale di compromessi degli store certificati root?

score 4 · Answer 1

In TLS non può esserci un record crittografato prima che la prima stretta di mano sia completata; il primo record crittografato inviato dal client o dal server è un messaggio Finished . Se il messaggio è crittografato, significa che deve essere decifrato dall'altra parte; poiché le chiavi di crittografia simmetriche derivano dal "segreto segreto" che deriva dal meccanismo di scambio delle chiavi concordato, l'estremità ricevente (qui, il server) non può decifrare logicamente un record prima del completamento di lo scambio di chiavi. Pertanto, dal client, non avrebbe senso inviare un avviso crittografato prima di ClientKeyExchange (ovvero, non solo eseguendo la crittografia prima che i messaggi Finished violassero lo standard, ma facendo così prima che ClientKeyExchange sarebbe anche infrangere le Leggi della Natura).

Questo porta a due teorie:

Forse il messaggio di avviso "crittografato" non è crittografato. Un record di avviso consiste in una sequenza di "allarmi", ognuno dei quali consiste in un paio di byte: il primo byte specifica il livello di avviso (1 = avviso, 2 = fatale), il secondo byte documenta la natura dell'avviso. Consulta il standard per i dettagli.
Forse la traccia della tua rete confonde il traffico proveniente da diverse connessioni TLS, e l'"avviso crittografato" appartiene a un'altra, vecchia stretta di mano (potrebbe essere l'avviso close_notify che segna la fine della precedente connessione).

In ogni caso, se il server richiede un certificato client (con un messaggio CertificateRequest ) e il client non ha un certificato adeguato, il comportamento del client deve essere quello di inviare un messaggio Certificate vuoto ( prima suo ClientKeyExchange ). Questo è ciò che dovrebbe accadere con TLS-1.0 e versioni successive; in SSL-3.0, un client senza un certificato adatto ometterebbe il messaggio Certificate del tutto, e invece invierà un messaggio di avviso di livello "warning" e digiterà "no_certificate" (valore numerico: 41). Se la tua traccia non mostra alcun messaggio di Certificate dal client, questo significherebbe che stai usando SSL-3.0, che, ad agosto 2015, è strano (i client e i server dovrebbero già conoscere TLS-1.0). Questo dovrebbe essere verificato osservando il contenuto dei messaggi ClientHello e ServerHello . Un handshake SSL-3.0 spiegherebbe il messaggio di "avviso", ma non sarebbe certamente crittografato.

(SSL-3.0 e TLS-1.0 sono molto simili, ma presentano alcune differenze, uno dei quali è il comportamento del client quando è stato richiesto un certificato ma non è possibile fornirne uno.)

Se stai usando veramente SSL-3.0, allora, prima di tutto, non dovresti, perché SSL-3.0 ha una debolezza irrimediabile (chiamata BARBONCINO ). Tuttavia, anche se si aggiorna a una versione migliore (una delle versioni TLS), si avrebbe probabilmente lo stesso problema, ovvero che il client non invia un certificato.

Le cause comuni sono:

Il client non ha, infatti, un tale certificato. Forse il certificato è lì ma è scaduto (o il cliente può crederlo, a causa di un orologio interno mal impostato). Forse il client ha il certificato ma manca la chiave segreta (ad esempio in un mondo Windows, i diritti di accesso sulla chiave privata sono disattivati).
Il client ha un certificato ma non è appropriato per il server. Il CertificateRequest dal server include l'elenco dei nomi della CA principale che il server utilizzerà per convalidare il certificato client. Il client invierà il proprio certificato solo se tali certificati possono essere convalidati relativamente a una di queste CA. Se l'elenco della CA principale non è configurato correttamente sul server, il client potrebbe semplicemente astenersi dall'inviare un certificato.
Allo stesso modo, il cliente può credere che il suo certificato non sia appropriato per il server. Questo è un caso raro ma si verifica in alcuni scenari che riguardano le migrazioni verso una nuova CA radice: data una PKI con una CA radice e una CA intermedia, si può creare una nuova CA radice (nuovo nome, nuova chiave) che emette un nuovo certificato per la CA intermedia (ma la CA intermedia mantiene il suo nome e la chiave). Questo tipo di migrazione consente di convalidare i certificati esistenti sia con la vecchia che con la nuova radice, il che è una buona cosa per una transizione senza intoppi. Tuttavia, alcuni software client (sì, Windows, ti guardo) funzionano nella convinzione che un dato certificato si riferisce a una singola CA radice, sempre. Quindi, in uno scenario del genere, se il server vuole usare la nuova root ma il client crede che il suo certificato provenga dalla vecchia root, il client non lo invierà, anche se avrebbe funzionato bene sul lato server.