Sto cercando un modo per proteggere i client da un attacco MITM senza usare una VPN e ToR. Il mio pensiero è che i certificati client potrebbero fare il lavoro, ma non ne sono del tutto sicuro poiché non è stato esteso troppo il supporto di server o browser in quest'area.
Qualcuno può dirmi se i certificati client forniscono una protezione MITM?
Questa protezione è solo per lo scambio di autenticazione o protegge l'intera sessione TLS?
C'è una buona risorsa per studiare questo in dettaglio?
Un attacco man-in-the-middle è quando un utente malintenzionato si inserisce tra il cliente e server, e impersona il client quando parla al server e impersona il server quando parla al client. "Impersonificazione" ha senso solo nella misura in cui è un'identità peer prevista; non puoi impersonare un cliente anonimo.
Dal punto di vista del server , se il client mostra un certificato e utilizza la sua chiave privata come parte di un messaggio CertificateVerify (come descritto nel standard SSL/TLS , sezione 7.4.8), e il server convalida il certificato del client per quanto riguarda un insieme di trust ancore che non include una radice ostile o incompetente CA, quindi il server ha la garanzia che stia parlando con il client giusto (quello identificato dal certificato client). La garanzia vale per tutti i dati successivi all'interno della connessione (essa NON si estende ai dati scambiati prima dell'handshake in cui il cliente ha mostrato un certificato, nel caso in cui l'handshake fosse una "rinegoziazione").
Ciò significa che un certificato client protegge in effetti dallo scenario specifico di una CA canaglia iniettata nell'archivio fidato client . In tale scenario, "l'attaccante" è riuscito a fare in modo che il client si fidasse di una CA radice specifica controllata dagli aggressori, consentendo all'aggressore di eseguire un attacco MitM creando al volo un certificato falso per il server di destinazione (questo è esattamente cosa succede con alcuni proxy "filtraggio dei contenuti SSL" che vengono distribuiti in alcune organizzazioni). Tale MitM interrompe l'autenticazione del certificato client, perché ciò che il client firma come parte di un messaggio CertificateVerify è un hash calcolato su molti dati, incluso il certificato del server - nello scenario MitM, il client non vede il certificato "giusto" e quindi calcola una firma errata, che il server rileva.
Dal punto di vista del client , if un certificato client è stato richiesto dal server e mostrato dal client, quindi il il client sa che il vero server rileverà qualsiasi MitM. Il client non rileverà il MitM stesso; e se c'è un attacco MitM in corso, il client sta davvero parlando con l'attaccante e l'attaccante non dirà al client "a proposito, sei attualmente sotto attacco".
In questo senso, un certificato client impedisce un vero MitM (noto anche come "rappresentazione a due lati") ma non protegge da frodi più semplici (rappresentazione unilaterale, ovvero server falsi).
Bottom line: In presenza di SSL con autenticazione client-server reciproca (entrambi inviano un certificato all'altro), un MitM di successo richiede che l'attaccante installi CA canaglia sia nel client che nel server. Tuttavia, se l'attaccante può piazzare una CA canaglia nel solo client, il client si trova ancora in una situazione piuttosto brutta (anche se un MitM completo viene bloccato).
Un certificato lato client, come qualsiasi tecnologia di chiave privata pubblica-privata, fornirà protezione contro MITM.
Il problema principale con i certificati lato client a tal fine è il phishing o l'autore dell'attacco che altrimenti recupera il certificato / chiave privata dall'utente finale, che di solito è molto più semplice di un server perché gli utenti finali non sanno molto sicurezza. Quando un utente malintenzionato ha recuperato il pk / certificato, può eseguire un attacco MITM inoltrando tutte le informazioni provenienti dal client, dal momento che può semplicemente crittografare nuovamente i dati utilizzando il pk / certificato.
Si noti che per un attacco MITM completo sono necessari sia i client che i server pk / certificati, poiché altrimenti una parte della comunicazione non può essere decifrata.
Se ti attieni alla definizione rigorosa di un MiTM (che non comporta manipolazioni di archivi di certificati), allora la risposta è fornita in TLS RFC, appendice F.1.1 :" Ogni volta che il server è autenticato, il canale è protetto contro gli attacchi man-in-the-middle ". Quindi per un MiTM puro, i certificati client non sono nemmeno necessari.
Leggi altre domande sui tag client-side web-browser tls certificates man-in-the-middle