Attacchi MITM su FIDO UAF e U2F [chiuso]

Question

Attacchi MITM su FIDO UAF e U2F [chiuso]

#1 da (0 voti)

5

Nella Sezione 6 di Panoramica di Universal 2nd Factor (U2F) , dove vengono discussi gli attacchi MITM - vicino alla fine della sezione, si legge:

It is still possible to MITM a user's authentication to a site if the MITM is 

a. able to get a server cert for the actual origin name issued by a valid CA, and 
b. ChannelIDs are NOT supported by the browser. 

But this is quite a high bar.

Non sono convinto che questa sia una battuta così alta. Abbiamo visto più di alcuni casi in cui gli hacker sono stati in grado di ottenere falso ma fidato Certificati firmati da CA . Inoltre, TLS ChannelID non è stato ampiamente adottato dalla maggior parte dei browser e server (infatti, la proposta di proposta RFC è scaduta nel 2013). Inoltre, anche se TLS ChannelID è supportato da entrambi gli endpoint, un utente malintenzionato MITM attivo potrebbe impedire l'utilizzo di TLS ChannelID tramite un attacco di downgrade durante il messaggio ClientHello.

Apprezzo il salto che FIDO ha compiuto per ridurre la dipendenza dalle password e rendere l'autenticazione più sicura e meno ingombrante per gli utenti. Ma sembra che abbia fatto ben poco per proteggersi da un attacco MITM in cui un aggressore è in grado di mettere le mani su un certificato falso ma attendibile, e dobbiamo continuare a dare piena fiducia e fiducia nelle CA, che hanno un storia di lasciarci andare. Ovviamente, anche il protocollo di autenticazione più sicuro è inutile se la connessione può essere compromessa da un aggressore MITM attivo.

Altri protocolli di autenticazione basati su chiavi (come SSH) proteggono dagli attacchi MITM tramite la chiave pubblica integrata nel protocollo. Con SSH, ad esempio, i client memorizzano le chiavi pubbliche dei server a cui sono connessi. Immediatamente dopo aver effettuato una connessione, durante lo scambio delle chiavi e prima che venga tentata qualsiasi autenticazione client, il client verifica che sia effettivamente connesso al server previsto, verificando che la chiave pubblica utilizzata dal server sia uguale a quella su file per quel server e assicurandosi che il server sia in possesso della chiave privata associata alla chiave pubblica tramite alcune operazioni di crittografia che richiedono la chiave privata.

Ovviamente, HPKP (senza FIDO) può essere usato per bloccare i certificati SSL / TLS dei siti nel browser, ma questo ha il suo propria serie di problemi .

Sono curioso di sapere perché gli architetti di FIDO UAF e U2F non abbiano portato il protocollo un ulteriore passo avanti e abbiano incorporato un metodo di blocco della chiave pubblica all'interno del protocollo (forse utilizzando diversi tipi di chiavi rispetto a quelli utilizzati per la connessione SSL / TLS ), in modo che i client possano assicurarsi di collegarsi al server legittimo prima di tentare l'autenticazione, a SSH. Qualcuno si preoccuperebbe di ipotizzare?

man-in-the-middle certificate-authority fido

posta weaver 20.04.2017 - 19:53

fonte

1 risposta

Leggi altre domande sui tag man-in-the-middle certificate-authority fido

UAC è abilitato e impostato su Elevate senza prompt in realtà una protezione di sicurezza? Problemi con Browser Crypto

score 0 · Answer 1

Condivido la tua sensazione globale che l'U2F sia un buon lavoro, anche se è un lavoro semiscompilato. :) Nota: sto lavorando come architetto della sicurezza all'interno di una piccola azienda (membro FIDO Alliance) con i suoi prodotti certificati U2F.

Per quanto riguarda il supporto in scadenza per ChannelID TLS, si suppone, in ogni caso, di evolvere nel supporto di Token Binding (specifiche aggiornate, stesso obiettivo). link Sì, non è facile implementare l'ID canale TlS sul lato server (la libreria BoringSSL può aiutare) e sì è supportato solo da Chrome sul lato client e sì, può essere declassato ... MA la cosa buona è che se stai pensando di usare U2F sul tuo server / servizio, può ancora essere fatto e puoi applicarlo. Meglio di niente mentre è vero che su molti servizi globali (gmail, facebook ...), la protezione ID canale TLS è semplicemente disattivata.

Per quanto riguarda il dibattito sul blocco delle chiavi e il motivo per cui la parte di autenticazione del server si basa sul certificato server SSL valido / scadente, la decisione originale è probabilmente un risultato misto di difficoltà tecniche e posizionamento "politico". U2F (e UAF) già attacca le autorità certificate stabilite sul lato client ... Nota: si tratta di coppie di chiavi dei client anonimi ma i certificati di attestazione / produzione associati possono essere firmati dalle chiavi private FIDO Alliance (diventando la propria Autorità di certificazione ...).

Affrontare l'autenticazione reciproca richiederebbe anche una memoria più grande ... Non mi interessa, ma può essere un problema per alcuni fornitori di soluzioni.

Qualunque sia la vera ragione iniziale, non è stato fatto e, per quanto ne so, questo tipo di funzionalità non è pianificato per le versioni future di U2F ... e non è pianificato per WebAuthN (tipo di successore U2F / UAF).

Ma non significa che U2F non possa essere adattato per supportare la funzione di autenticazione reciproca migliorata ... ci sto lavorando con pochi altri pazzi: benvenuto alla nostra follia:)