L'elemento Keygen dovrebbe essere utilizzato per creare un certificato per l'autenticazione reciproca TLS? Quali alternative ci sono?

Per eseguire l'autenticazione client basata su certificati con SSL, il client deve "possedere" un certificato, cioè avere accesso a una chiave privata e al corrispondente certificato (rilasciato da una CA che il server accetterà). Quando il client è il browser Web, non c'è modo di evitarlo: il browser deve conoscere la chiave in quanto tale.

Ci sono due modi in cui il browser può "conoscere" una coppia privata + una coppia di certificati:

1. Fai in modo che la CA generi la coppia di chiavi, crei il certificato e impacchetta il tutto come file PKCS # 12 / PFX che viene poi importato nel browser.
2. Avere il browser generare la coppia di chiavi, inviare la chiave pubblica alla CA, che genera il certificato; il certificato viene quindi importato nel browser.

Il secondo metodo è spesso considerato "migliore" in un modo generico. In particolare, se il certificato deve essere utilizzato successivamente per la firma dei documenti, in modo giuridicamente vincolante, i dettagli del ciclo di vita della chiave sono importanti per il valore legale; i dettagli sono complessi e dipendono molto dalle leggi locali, ma, come sommario, se la chiave privata esiste, anche in modo transitorio, su un sistema diverso dal computer dell'utente, allora non funzionerà. Tuttavia, in uno scenario autenticazione , specialmente per una sessione SSL / TLS, questo potrebbe non essere un problema.

L'elemento <keygen> è il modo HTML5 di implementare il secondo modello. In realtà è più vecchio di HTML5 e ha le sue radici in Netscape Navigator. Vedi questa pagina e che file per i dettagli su come usarlo. Per Internet Explorer, dovrai utilizzare un modo specifico di Microsoft, che è stato chiamato Xenroll ma è stato ritirato a favore di CertEnroll (vedi questo post del blog per un'introduzione). Microsoft si è dimostrata riluttante ad implementare <keygen> , ufficialmente perché a loro non piace quello che fa .

Ad ogni modo, se si esegue l'autenticazione con certificato a livello SSL, è necessario fare i conti con il tipo di interfaccia utente e l'esperienza supportata dai browser, il che non è assolutamente ottimale dal punto di vista ergonomico. Le alternative includono l'autenticazione all'interno del tunnel SSL, che, in un contesto Web, significa qualcosa che l'utente digita (password o equivalente click-o-matic) o trucchi Javascript. Il problema con Javascript è che non ha accesso al repository del sistema operativo client per le chiavi private (e l'interfaccia per le smartcard) a meno che alcuni vengono utilizzate le funzioni non standard .

L'autenticazione basata su certificato in SSL / TLS è non necessariamente " più sicuro "rispetto ad altri metodi di autenticazione. I certificati consentono di separare identificazione dall'autenticazione . È una funzionalità piacevole, ma è inutile nei sistemi in cui l'architettura generale non richiede tale separazione.

Penso che ci siano molti svantaggi nell'utilizzo dell'elemento keygen, in quanto è già elencato nel tuo post. Se hai un webservice che dovrebbe essere facilmente accessibile e compatibile con molti client, è abbastanza difficile implementare l'autenticazione lato client usando keygen, una soluzione abbastanza nuova e poco matura.

La soluzione migliore sarebbe quella di fornire token di crittografia ai tuoi clienti, con certificati precaricati, firmati dalla tua CA. Naturalmente, questo aggiunge molta complessità, perché devi gestire la generazione e la distribuzione dei certificati client, il che può essere molto difficile da fare se hai molti client e nessuna infrastruttura per una CA. Il vantaggio di questa soluzione sarebbe un meccanismo di autenticazione molto strong per i tuoi clienti.

Se stai solo cercando di prevenire gli attacchi MITM, l'utilizzo di SSL e un buon meccanismo di accesso utente / password potrebbero essere sufficienti nella maggior parte dei casi.

Dipende molto da quali risorse hai, da cosa stai cercando di proteggere e da chi e chi sono gli utenti della tua applicazione. Rispondere a queste domande sarebbe il primo passo nel processo di costruzione di un sistema sicuro.

Aggiornamento:

Riguardo al modello di minaccia che hai descritto, non penso che il tuo modello offra protezione contro CA compromessa. Ecco un esempio:

• Una CA è compromessa e viene emesso un certificato per il tuo dominio
• Il DNS del client viene compromesso in modo che risponda con l'IP dell'utente malintenzionato, quando viene interrogato per il tuo dominio
• Il client tenta di connettersi, stabilisce una connessione con il server canaglia, che a sua volta si connette al tuo server
• Il server canaglia agisce come un client che si connette da un nuovo dispositivo e viene generato un nuovo certificato client.
• Anche se il vero client invia il suo certificato esistente, il server canaglia lo ignorerebbe.

L'attacco descritto sopra presuppone che un client possa avere più certificati (uno per ogni dispositivo da cui si sta connettendo). Se non si desidera implementare questo comportamento, sarebbe molto difficile per un normale cliente copiare il certificato su ogni dispositivo che sta utilizzando e, naturalmente, un'esperienza utente negativa.

Tutto sommato, la protezione dalle CA compromesse è un compito arduo, e penso che finché non saranno implementate su larga scala nuove tecnologie come DNSEC, non ce n'è molto che si possa fare.

Dall'altro lato, l'hacking di una CA ben nota non è qualcosa che accade ogni giorno. Assicurati di non acquistare un certificato da una CA non propria e per il momento dovresti essere abbastanza sicuro.