Perché è necessario il messaggio CertificateVerify? (Perché l'autenticazione del client non viene eseguita tramite KeyExchange)

Question

Perché è necessario il messaggio CertificateVerify? (Perché l'autenticazione del client non viene eseguita tramite KeyExchange)

#1 da (0 voti)

1

Perché l'autenticazione del client non viene eseguita attraverso KeyExchange come con il server, ma attraverso un messaggio CertificateVerify ?

EDIT: per essere più chiari:
Quando si utilizza lo scambio di chiavi RSA, il client crittografa il materiale chiave con la chiave pubblica del server in modo che solo il server reale (che ha la chiave privata) possa decrittografarlo. [ RFC5246: 7.4.7.1 ] Perché il client non firma anche la chiave materiale con la sua chiave privata quando si utilizza l'autenticazione client?

Quando si usa lo scambio di chiavi Diffie-Hellman il server firma i suoi parametri chiave usando la sua chiave privata per dimostrare che ha la chiave privata (e quindi è il vero server). [ RFC5246: 7.4.7.2 ] Perché il client non firma anche i parametri quando si utilizza l'autenticazione client?

Invece di questi metodi (penso più logici), il client invia un messaggio CertificateVerify con una firma su tutti i messaggi di handshake. Perché viene scelto questo metodo?

EDIT: si applica solo ai certificati con capacità di firma, perché con es. l'autenticazione del client dei certificati DH statici è eseguita durante KeyExchange. [ RFC5246: 7.4.8 ]

authentication tls certificates

posta SWdV 08.01.2016 - 22:22

fonte

1 risposta

Leggi altre domande sui tag authentication tls certificates

Questo file pdf incorpora un exploit o malware? Come trovare quale dominio nel mio VPS ha attivato un attacco DDoS con WP xmlrpc

score 0 · Accepted Answer

La tua idea non funziona. Essere in grado di firmare il materiale chiave non dimostra che il client abbia la chiave privata corrispondente al certificato.

L'autenticazione viene solitamente eseguita tramite un protocollo challenge-response in cui una delle parti presenta una domanda e l'altra parte fornisce una risposta valida per dimostrare che conosce la regola di trasformare le domande in risposte. Il materiale chiave (qui funge da domanda) nel ClientKeyExchange è determinato esclusivamente dal client mentre il server non ha alcun controllo su di esso. Quindi è come fare in modo che il cliente risponda alla sua domanda. Senza conoscere la "regola" (la chiave privata), il cliente può ancora fornire una risposta valida (materiale chiave firmato). Ad esempio, un utente malintenzionato può prendere il certificato e il materiale della chiave firmata da un altro client e successivamente impersonare quel client quando comunica con il server. Per ottenere il certificato e il materiale della chiave firmata dalla vittima, l'utente malintenzionato può stabilire il proprio server e fare in modo che qualcuno si connetta a lui.

In realtà, l'hash firmato nel messaggio CertificateVerify include informazioni sia dal client che dal server (ad esempio, la "domanda" è determinata da entrambe le parti). Quindi il cliente non risponde alla sua stessa domanda.
L'autenticazione del client è facoltativa in una transazione SSL / TLS. Considerando la chiarezza e la facilità di implementazione, non è una buona idea avere un messaggio con due forme.

Il messaggio CertificateVerify non è strettamente necessario. È corretto fonderlo in ClientKeyExchange a condizione che i materiali da firmare siano scelti con cura. Tuttavia, è meglio avere un messaggio separato poiché svolge un ruolo indipendente. A proposito, un messaggio separato non costa necessariamente un ulteriore segmento TCP. È molto comune incorporare più messaggi in un segmento in modo che un messaggio separato non introduca costi aggiuntivi.