Autenticazione client durante TLS / SSL e Replay-Attacks

Question

Autenticazione client durante TLS / SSL e Replay-Attacks

#1 da (2 voti)

1

Ho trovato questa spiegazione su come funziona un'autenticazione client durante SSL- Stretta di mano . Quindi, secondo Oracle, l'autenticazione client funziona come segue:

Il client invia il suo certificato, i dati casuali e una firma di tali dati casuali sul server.
Server verifica la firma dei dati casuali utilizzando la chiave pubblica nel certificato.
Il server controlla il periodo di validità del certificato.
Il server verifica se la CA nel certificato è una CA attendibile.
Il server utilizza la chiave pubblica della CA per verificare la firma nel certificato.

Dopo questi cinque passaggi l'utente è autenticato.

Domanda: Se un attaccante ottiene il certificato utente, i dati casuali e la firma di tali dati casuali, l'attaccante è in grado di avviare un attacco di replay?

Penso che i dati casuali debbano essere chellange per prevenire contro un replay-attack. Quindi qual è il modo comune per autenticare un utente utilizzando un certificato client?

authentication public-key-infrastructure tls certificates

posta MuratAbi 23.02.2017 - 16:15

fonte

1 risposta

Leggi altre domande sui tag authentication public-key-infrastructure tls certificates

Quale indirizzo IP viene utilizzato quando si risponde a un'e-mail mentre si utilizza una VPN? Quanto privacy offre realmente i servizi di privacy di whois?

score 2 · Answer 1

Penso che tu non abbia compreso appieno come funziona l'autenticazione del client e l'articolo che citi lo descrive solo in modo semplificato. Per citare questo articolo:

The SSL protocol requires the client to create a digital signature by creating a one-way hash from data generated randomly during the handshake and known only to the client and server.

La parte di importazione è che questi non sono dati casuali generati dal solo client ma quella parte dei dati casuali è generata dal client e altri dati casuali sono generati dal server. O per dirlo in modo più corretto: il cliente firma tutti i messaggi inviati e ricevuti finora con il suo certificato. Questi messaggi includono tra gli altri anche dati casuali a 256 bit generati dal client e altri dati casuali a 256 bit generati dal server. Consulta la sezione RFC 5246 (TLS 1.2) 7.4.8 per i dettagli.

If an Attacker gets the User certificate, the random-data and the signiture of that random-data, is the attacker able to start a replay-attack?

Poiché la firma nel messaggio CertificateVerify dipende anche da dati casuali generati dal server, un attacco di replay può essere eseguito solo se il server utilizza gli stessi dati casuali in una stretta di mano come in un handshake precedentemente rilevato dall'attaccante. Ma questo può accadere solo se il generatore casuale nel server è gravemente danneggiato o se l'attaccante è estremamente fortunato perché il la probabilità che il server usi esattamente lo stesso numero casuale a 256 bit di una precedente stretta di mano è quasi pari a zero.