Scenario man-in-the-middle per TLS

10

Considera lo scenario seguente: desideri comunicare in modo sicuro con a.com e ti fidi solo del certificato radice di VeriSign.

a.com presenta un certificato firmato da VeriSign con CN = a.com, quindi ti fidi che stai effettivamente comunicando con a.com.

Eve ha anche ottenuto un certificato da VeriSign per il suo sito b.com. In questo modo, poteva creare un nuovo certificato con CN = a.com e firmarlo con il certificato ottenuto da VeriSign.

In questo modo, Eve ha un certificato per CN = a.com firmato dal suo certificato per b.com, che è firmato da VeriSign stesso, quindi anche tu ti fideresti. Cosa deve impedire a Eve di eseguire un attacco man-in-the-middle?

    
posta Georgios Bitzes 03.04.2013 - 03:01
fonte

4 risposte

11

Eve potrebbe firmare un certificato indicando "a.com" come nome, con la sua chiave privata, ma il browser di Bob non lo accetterà. Quando il browser di Bob convalida una catena di certificati, verifica tutte le firme, ma non solo la firma. L'algoritmo di convalida completo è complesso; vedi lo standard . In questo caso, il browser di Bob solleverà un sopracciglio metaforico quando si applica check (k) dalla sezione 6.1.4: Il certificato di Eve è un certificato "versione 3", ma non contiene un'estensione Basic Constraints , o la sua estensione Basic Constraints ha il flag cA impostato su FALSE .

In breve, anche se la certificazione è una sorta di delega di potere, la potenza di emettere certificati viene specificata per richiedere una delega esplicita e non viene eseguita per impostazione predefinita. Come dice @Terry, CA commerciale può garantire i certificati di sub-CA, con il flag cA impostato su TRUE , ma si caricheranno molto per quello. In effetti, vincoleranno contrattualmente la CA secondaria al rispetto della Dichiarazione sulla certificazione della CA (vedere ci per il CPS di Verisign). Gli obblighi contrattuali comprendono un sacco di chiacchiere con assicurazioni e cose del genere, in modo che una CA-CA che emette certificati falsi verrebbe buttata nel dimenticatoio dalla rappresaglia legale di Verisign. Non fanno prigionieri.

Le cose non funzionavano in quel modo nel passato. La prima versione di X.509 non supportava le estensioni, quindi i client dovevano trovare un altro modo per verificare se una determinata entità avesse o meno la potenza CA. Ciò era inopportuno, poiché i browser dovevano scegliere tra l'incorporamento di un elenco crescente di "CA subordinata consentita" o semplicemente affidarsi a tutti i certificati con CA power (consentendo così l'attacco). Si noti che fino all'anno 2003 o giù di lì, c'era un bug in Internet Explorer: IE non controllava affatto l'estensione Basic Constraints ! Quando questo è stato scoperto, è stato prontamente aggiornato, naturalmente ...

    
risposta data 03.04.2013 - 14:58
fonte
6

Hai un malinteso su come funziona la procedura di firma del certificato.

Nella maggior parte dei casi, Eve non può firmare i certificati con il certificato che ottiene da Verisign. Il browser rifiuterà il certificato firmato da Eve.

Per Eve firmare i certificati con il certificato che ottiene da Verisign, deve ottenere un certificato contenente l'estensione del vincolo di base con il flag cA impostato su TRUE . Inutile dire che tali certificati sono molto più costosi.

    
risposta data 03.04.2013 - 03:44
fonte
5

Tali certificati che potrebbero consentire a Eve di firmare un certificato per a.com sono talvolta disponibili, sebbene siano altamente controverso . Alcune CA sono state meno responsabili dell'emissione di tali certificati (Trustwave, Turktrust , ecc.), Mentre altri hanno controlli severi (contrattuali, politiche, audit) per impedire la creazione di certificati che potrebbero essere utilizzati per gli attacchi MiTM.

GlobalSign, ad esempio, ha un prodotto che potrebbe essere utilizzato per gli attacchi MiTM in teoria, ma i requisiti contrattuali e tecnici e gli audit ne impediscono l'utilizzo (anche in teoria). Nei casi in cui i controlli tecnici non sono possibili, il cliente verrebbe sottoposto a revisione e avrebbe gli stessi requisiti tecnici di un'autorità di certificazione indipendente.

Il maggior rischio di creare certificati MiTM è l'hacking di una CA (direttamente tramite un rivenditore fidato). È successo in passato ( Comodo , DigiNotar ), e probabilmente accadrà di nuovo.

Come ha detto Terry, i normali certificati che si ottengono da una CA non sono in grado di firmare altri certificati.

    
risposta data 03.04.2013 - 04:16
fonte
0

Fondamentalmente non puoi firmare un certificato usando un altro certificato. I certificati contengono solo chiavi pubbliche.

  • Un certificato è firmato digitalmente utilizzando la chiave privata (e alcuni altri parametri in base allo standard che si sta utilizzando) del mittente.
    • Un certificato è firmato da VeriSign utilizzando la sua chiave privata. E il tuo browser convalida il certificato utilizzando il certificato di VeriSign (chiave pubblica).
    • Se Eve vuole firmare un certificato, userebbe la sua chiave privata, ma il certificato verrà considerato non valido dal browser in quanto non ha il certificato digitale di Eve nell'elenco delle CA di fiducia.
risposta data 03.04.2013 - 06:22
fonte

Leggi altre domande sui tag