In che modo Convergence (sostituzione CA) impedisce anche ai suoi notai di essere MITM?

I dettagli su Convergence si trovano nel Perspectives Project , in particolare il corrispondente articolo di Taiwan .

Un utente malintenzionato in grado di "nascondere" il server da tutti i notai (per lo più un attaccante che lavora principalmente sulla rete locale del server) è ciò che gli autori chiamano L _server modello. In definitiva, quell'attacco "funziona" con i notai predefiniti, che usano "prospettiva di rete". Vale a dire, i notai vedranno il certificato dell'attaccante come "un nuovo certificato per il server", che è valido. Tuttavia, non appena l'attaccante interrompe l'attacco attivo, il vecchio certificato diventa nuovamente visibile e questo solleva i flag di avviso nei notai: un aggiornamento del certificato è sicuramente valido, la ricomparsa di un vecchio certificato è indicativa di gioco scorretto al lavoro.

Tuttavia, nulla impedisce ai notai di utilizzare altre strategie di convalida, inclusa la convalida basata su CA, che ha i suoi problemi ma resiste a MitM.

Ci sono due idee principali in quel sistema:

• Delega la convalida a server esterni (i notai), utilizzando diversi con un quorum di consenso per evitare singoli punti di fiducia. Questo tipo di delega esiste già nel contesto del bestiario X.509, sotto il nome SCVP (ma il protocollo Convergence è molto più semplice).

• I notai usano la memoria per migliorare la sicurezza. Laddove un normale server SCVP farebbe affidamento sulla validazione context-free (il vero modo X.509) con forse un po 'di caching a breve termine ma solo per risparmiare sui costi della CPU, i notai di Convergence si basano principalmente sulla stabilità temporale: assumono che il server SSL i certificati di solito rimangono invariati per uno o più anni, per un determinato server; quindi possono semplicemente verificare che un certificato del server SSL sia ancora lo stesso di prima. X.509 e SCVP potrebbero gestire un server che riceve un nuovo certificato ogni 5 minuti, il che è fantastico ma completamente inutile nella pratica.

Una delle pietre miliari del ragionamento di Convergence è che se un utente malintenzionato riesce a sconfiggere i controlli eseguiti dai notai, sarà anche in grado di impersonare il server quando parla con la CA tradizionale, e quindi potrebbe anche sconfiggere il modello CA tradizionale. Quindi, per quanto riguarda la sicurezza, la convergenza non è peggiore della situazione attuale. Si noti che X.509 potrebbe fare molto meglio; in particolare, la revoca non è realmente supportata da Convergence e Convergence non è peggiore della CA tradizionale, soprattutto perché i client esistenti tendono a non controllare comunque la revoca.

Quindi in realtà Convergence non significa rendere SSL più sicuro, ma piuttosto eliminare la CA esistente senza abbassare la sicurezza generale.

Potenzialmente , un notaio può eseguire qualsiasi processo di convalida che desidera, inclusa la normale convalida del percorso X.509 (e quindi evitare il tipo di MitM suggerito). Poiché ci si potrebbe aspettare che ci siano molti meno notai dei clienti, e quei notai sarebbero più "attenti alla sicurezza", possiamo concludere che la in qualche punto futuro Convergenza potrebbe effettivamente migliorare la sicurezza Web. La conseguenza più immediata dell'uso diffuso della convergenza, tuttavia, sarebbe uno spostamento di potere: il Game Master non sarebbe più Microsoft (che decide quale CA entra nell'elenco riconosciuto per default da Internet Explorer), ma piuttosto chi gestisce il notaio con il la migliore connettività di rete che i client userebbero per impostazione predefinita (presumibilmente Google).

Il progetto Convergence si basa sul Perspectives Project della Carnegie Mellon University. The Perspectives Project ha un po 'più di informazioni su questo. ( Vedi anche il loro articolo )

Se l'attaccante si trova vicino al sistema di destinazione, ciò sarebbe possibile, ma davvero difficile da eseguire. Dalla carta:

Lserver + k · nm Compromise: This attack is stronger than the previous Lclient + k · nm scenario, since control over the destination service’s link means that even legitimate notaries will observe the attacker’s key. As a result, even if fewer than q notaries are compromised, the client relies entirely on temporal safety.

Dove "sicurezza temporale" è definita come:

Instead, we use the concept of “temporal safety”, which means that a client will be safe as long as its quorum duration threshold is larger than the actual duration of the attack

La carta dice anche che:

While our model allows any network or notary component to be compromised, we borrow from Abraham Lincoln and assume that an attacker “can fool all of the [components] some of the time, and some of the [components] all of the time, but it cannot fool all of the [components] all of the time.” That is, we assume that attacks are either: (1) localized to a particular network scope or (2) of limited duration, since a larger attack is more easily detected and remedied

Quindi questo sembra essere un problema se nessuna chiave è memorizzata nella cache dal client e dai server notarili (dato che memorizzano anche la chiave nella cache). Se l'attaccante può ingannare tutti i sistemi tutto il tempo, sarebbe possibile. Ma dovrebbe essere ancora più sicuro di adesso, dove abbiamo un unico punto di errore.

La mia comprensione di questo funziona in questo modo:

Se un utente malintenzionato ha inoltrato tutto il traffico attraverso il proprio server, allora sì, potrebbe bloccare il traffico ai notai.

Non potevano modificare il traffico tra il client ei notai perché il client ha già una copia del certificato notarile memorizzato localmente, quindi se la risposta del notaio non corrisponde al certificato che il client ha memorizzato, il client non dovrebbe accetta la risposta.

[EDIT]

Attualmente esiste un fork del server notarile di Convergence che utilizzerà l'aiuto di Google ( Ricerca del certificato Google ) per verificare che il certificato sia stato visualizzato in modo coerente.