Una CA radice compromessa può impersonare un certificato SSL?

Question

Una CA radice compromessa può impersonare un certificato SSL?

#1 da (8 voti)
#2 da (3 voti)

2

La mia domanda riguarda gli attacchi MITM contro https e come questi verrebbero visualizzati all'utente finale.

Supponete che una CA radice affidabile sia stata compromessa / costretta a produrre certificati SSL fraudolenti. Che cosa sarebbero in grado di ottenere tali certificati, in particolare sugli attacchi di tipo MITM?

Ad esempio, prendi Facebook, se vado lì ottengo (1) un lucchetto, (2) un certificato firmato da DigiCert e (3) Posso controllare che l'impronta digitale SHA corrisponda al valore 81: AB: ecc.

La mia ipotesi è che se DigiCert fosse la CA compromessa, allora un certificato falso che corrisponde a 1, 2 e amp; 3 potrebbe essere prodotto, è corretto? C'è qualcos'altro nel modello di sicurezza SSL che renderebbe un certificato falso distinguibile dal vero certificato SSL che è stato effettivamente emesso su Facebook? O qualcos'altro che consentirebbe il rilevamento di attacchi di tipo MITM basati su questo certificato?

Il mio secondo presupposto è che se una CA diversa da DigiCert fosse la CA compromessa, allora potrebbe essere prodotto un certificato falso, ma non direbbe "DigiCert" su di esso, e non corrisponderebbe in termini di chiave SHA ? È corretto o sarebbe possibile (puramente da un punto di vista tecnico) per una CA radice creare un certificato impersonando un'altra CA radice? In tal caso, ci sarebbe un altro modo per rilevare che una connessione è stata crittografata con questo falso certificato? Potrebbe un'altra CA creare un certificato che sembra avere la stessa chiave SHA?

Questa domanda è ispirata all'imminente "carta dei ficcanaso" della Gran Bretagna che è destinata a fornire alle autorità molti poteri per spiare le comunicazioni digitali. Il punto è l'utilità di tali poteri di fronte alla crittografia, in quanto si è parlato dell'utilizzo di "scatole nere" che eseguivano un'ispezione approfondita dei pacchetti per raccogliere informazioni che i fornitori (ad esempio Facebook) potrebbero non scegliere di condividere con il governo di Sua Maestà. La mia ipotesi era che tali tecniche non fossero possibili (certamente non con DPI, mi auguro!), Ma le possibilità di falsi certificati e attacchi MITM non mi sono davvero chiare. Immagino che non sarebbe stato tentato se non altro per ragioni politiche, supponendo che i falsi certificati possano essere rilevati da clienti esperti di tecnologia.

encryption tls man-in-the-middle

posta daveonhols 02.07.2015 - 23:02

fonte

2 risposte

Leggi altre domande sui tag encryption tls man-in-the-middle

Protezione dalla copia nelle schede SD Crittografia PGP - Qual è la necessità di crittografare usando una chiave casuale una tantum? [duplicare]

score 8 · Answer 1

Tali compromessi sono già accaduti e DigiNotar è solo un esempio. In effetti, l'autore dell'attacco può impersonare quasi tutti i certificati in questo modo, perché per la maggior parte dei certificati non importa chi ha firmato ma solo che è stato firmato da una CA attendibile dal browser.

Ci sono alcune eccezioni che sono quindi più sicure:

Chrome e Firefox (e IE con EMET?) hanno l'impronta digitale della chiave pubblica per alcuni siti molto importanti codificati ( bloccato ) nel browser / sistema operativo. In questo caso verrà rilevato il certificato falso, come è stato fatto nel caso DigiNotar.
Con i siti HPKP puoi offrire le loro chiavi per bloccarli nel browser al primo utilizzo, anche se il browser non è stato spedito con queste chiavi pre-pinned.
I certificati di convalida estesa (EV) possono essere emessi solo dalla CA selezionata, che è codificata in modo rigido nel browser.

Ovviamente si potrebbe in teoria rilevare certificati rilasciati erroneamente confrontando l'impronta digitale. Ci sono estensioni come Certificate Patrol che notificano all'utente se il certificato di una visita precedente il sito è stato modificato, ma spetta a ciascun utente decidere se il cambiamento è corretto o se si tratterebbe di un attacco. Estensioni come Prospettive cercano di semplificare questo processo confrontando il certificato con i certificati visti da altri utenti . Ma nessuna di queste strutture è attualmente fornita con i browser.

Si noti che questa ricreazione dei certificati viene spesso eseguita legalmente in SSL che intercetta i firewall, che devono poter accedere al contenuto decrittografato per rilevare gli attacchi. Ma in questo caso la nuova CA radice viene esplicitamente aggiunta al browser come attendibile. Per queste CA, che non sono fornite con il SO / browser, HPKP e pre-pinning vengono generalmente ignorati dal browser.

score 3 · Answer 2

La compromissione di una CA radice non significa che tutti i certificati firmati da quella radice attendibile siano effettivamente compromessi. Piuttosto, significa che i certificati fraudolenti possono essere fatti per attacchi man-in-the-middle e firmati in modo che appaiano attendibili in un browser.

Quando invii la richiesta di firma del certificato (CSR) a un'autorità di certificazione (CA), stanno firmando la tua chiave pubblica. Questo indica che hanno convalidato la tua proprietà del dominio, insieme a qualsiasi altro protocollo richiesto da CA, per dimostrare la tua identità. Dal momento che non invii la tua chiave privata, ciò non consente loro di essere in grado di decrittografare il tuo traffico, in quanto la tua chiave privata rimane privata.

È molto difficile compromettere una CA radice. Per essere considerati affidabili dai browser, esistono requisiti rigorosi per la sicurezza. Ciò include la "cerimonia chiave" che rende efficace la firma di qualsiasi cosa con la chiave radice in un'operazione molto macchinosa e autorizzata. Questo è il motivo per cui la maggior parte dei segni di CA con un intermedio, piuttosto che direttamente dalla radice.

Se qualcuno dicesse di compromettere la chiave di firma intermedia di DigiCert, potrebbe rilasciare tutti i certificati che desidera. Tuttavia, non controllerebbero ancora il DNS per quei domini. Potrebbero tuttavia, ad esempio, hackerare DNS su un router aziendale o domestico e condurre un attacco man-in-the-middle per, diciamo, Facebook, senza che il browser mostri un avviso. L'attacco userebbe il loro sito Web compromesso da DNS per essere un proxy di Facebook dove potrebbero intercettare il traffico.

Questo viene fatto su larga scala dai firewall aziendali con intercettazione SSL (sostituiscono i certificati SSL con i propri, che sono attendibili da tutte le workstation, e quindi ricodificarli con il certificato giusto e inviarli all'esterno). È fatto anche da paesi come la Cina, che richiedono che il loro CA sia considerato affidabile da tutti i computer e conducano attacchi middleman SSL come questo, naturalmente.

Un certificato appena generato non corrisponderebbe all'impronta digitale SHA della chiave precedente. Qualsiasi piccola differenza in un file o stringa hash con SHA sarebbe molto diversa da un'altra versione a causa di ciò che viene definito come "effetto valanga" nell'hashing. Tuttavia, ciò non avrà importanza per la fiducia del browser: le persone sostituiscono i certificati sempre e i browser non controllano la costante restante dell'hash. Al contrario, utilizzano CRL (Certificate Revocation List) o il più moderno OCSP (Online Certificate Status Protocol) per interrogare la CA e verificare se un certificato è stato revocato o compromesso. Questo è il secondo livello di difesa contro una catena di certificati compromessa.

Al di fuori di OCSP / CRL, tuttavia, solo la vigilanza dell'utente può rilevare una catena di certificati potenzialmente compromessa. Questo è il motivo per cui credo che sia da tempo in arrivo che un sostituto per il modello di catena di affidabilità della CA sia ampiamente implementato, ad esempio DNSSEC.