Limitazioni di sicurezza dell'autenticazione del client TLS (dai browser)

Question

Limitazioni di sicurezza dell'autenticazione del client TLS (dai browser)

#1 da (3 voti)

2

Supponiamo che ci siano due server che eseguono TLS. Entrambi i server hanno certificati di punto finale validi. In altre parole, nessuno dei due avrebbe sollevato un avviso dai browser dopo che la connessione è stata stabilita.

Esiste un modo per abusare dell'autenticazione client richiesta da un server per creare una connessione valida all'altro server? Per TLS 1.2 l'autenticazione finale viene eseguita utilizzando il messaggio Finished contenente verify_data che viene calcolato su tutti i messaggi di handshake. È abbastanza per prevenire un attacco man-in-the-middle anche se c'è un server malintenzionato attendibile in gioco? Che dire dei precedenti protocolli TLS 1.1, 1.0 e SSLv3?

Uno dei due server può essere considerato dannoso. Il server dannoso può utilizzare lo stesso indirizzo Web con un certificato client valido da una catena e una chiave privata diverse. Qualsiasi suite di cifratura è valida anche se quelle che sono comunemente abilitate nei browser hanno ovviamente una preferenza per un utente malintenzionato. Non penso che importi molto, ma supponiamo che l'autenticazione del client sia eseguita usando i certificati X509v3 usando il padding PKCS # 1 v1.5 con SHA-256 come algoritmo di firma.

authentication tls man-in-the-middle challenge-response

posta Maarten Bodewes 11.07.2015 - 10:52

fonte

1 risposta

Leggi altre domande sui tag authentication tls man-in-the-middle challenge-response

Si tratta di una pesca bot per vulnerabilità di sicurezza sul mio sito? esiste un modo per scaricare indirettamente rapidamente una cella moneta per sconfiggere un meccanismo anti-manomissione?

score 3 · Accepted Answer

Mentre la tua domanda sembra complessa, penso che si riduca alla seguente configurazione:

due server, il client non sa quale sia quello corretto
entrambi richiedono l'autenticazione con i certificati client

E la tua domanda è, se il client si autentica contro il server A: può questo server utilizzare l'autenticazione client di successo per autenticarsi contro il server B? La risposta è no, perché il server A non ha la chiave privata del client, solo la prova che il client conosce la chiave privata. E poiché non sa che il server a chiave privata A non può provare a B che conosce la chiave. Per i dettagli su questo processo vedi Come funziona SSL / TLS? dove si afferma : "CertificateVerify: una firma digitale calcolata dal client su tutti i precedenti messaggi di handshake.". E poiché i messaggi di handshake sono diversi tra client e B per client e A non è possibile riprodurre semplicemente CertificateVerify ma la chiave privata del client è necessaria per creare un nuovo CertificateVerify.

La situazione sarebbe diversa se non fossero coinvolti certificati client, cioè solo nome utente e password. In questo caso il server A otterrebbe le credenziali e potrebbe usarle per identificarsi rispetto al server B (phishing classico).

La situazione sarebbe anche diversa se il server A fosse solo in avanti tra il client e il server B senza modificare i messaggi. In questo caso A non è possibile annusare o modificare i dati ma se il server B considera l'indirizzo IP in cui ha ottenuto il certificato client come attendibile per altri scopi, questo trust potrebbe quindi essere utilizzato dal server A.