it-swarm-eu.dev

perché un'autenticazione client non viene comunemente eseguita nel protocollo TLS?

Esiste un motivo diverso dalla gestione della chiave/certificato sul lato client?

37
naresh

Che cos'è l'autenticazione? Questo assicura che chiunque si trovi all'altra estremità del tunnel sia chi credi. Dipende molto dal tipo di identità che vuoi usare.

Per la maggior parte dei siti Web, l'idea interessante è continuità. A loro non importa davvero chi è collegato; infatti, il punto di un sito Web deve essere leggibile da tutti. Il tipo di autenticità che un sito Web desidera ottenere è assicurarsi che due richieste successive provengano realmente dallo stesso client (chiunque sia quel client). Questo perché l'esperienza del sito Web è quella di una successione logica di pagine, guidata dalle azioni dell'utente (i collegamenti su cui fa clic), e immischiarsi in quel quadro simile a un film è ciò che l'attaccante sta cercando. L'utente e i progettisti del sito Web pensano in termini di sessioni e l'attaccante vuole dirottare la sessione.

Questa autenticità è raggiunta da diversi meccanismi:

  • Le richieste HTTP successive dallo stesso client passano attraverso la stessa connessione (con la funzione "keep-alive").
  • SSL offre un meccanismo di ripresa della sessione, che riutilizza la chiave condivisa negoziata (si tratta della "stretta di mano abbreviata" descritta nella sezione 7.3 dello standard SSL/TLS ).
  • La richiesta HTTP può includere un cookie che il server sceglie; in genere, un valore casuale specifico dell'utente viene inviato come cookie all'utente e, vedendolo tornare nelle richieste successive, il server è convinto che le richieste provengano dallo stesso utente.

Il cookie è sufficiente per garantire la continuità.

Quale valore aggiunto aggiungerebbero i certificati client? Bene, non molto. Certificati sono un modo per distribuire i collegamenti chiave/nome. Esistono principalmente tre scenari in cui i certificati client (in un contesto Web) sono rilevanti:

  1. Il server Web ha bisogno di una nozione estesa di identità dell'utente, che è definita da qualcun altro. Ad esempio, immagina un servizio governativo a cui i cittadini possono accedere, ma solo dopo un'autenticazione adeguata, ad es. un sistema elettorale online. Ciò che rende il cittadino, con il suo nome definito e la sua data di nascita, è gestito dallo Stato in generale, ma non è la stessa parte di quello che gestisce il servizio. I certificati dei clienti sono quindi un modo per trasportare l'autenticazione dal PKI che ha rilasciato il certificato al cittadino, al sistema elettorale online che non ha affatto il diritto di dire chi è il nome, ma deve comunque tenere traccia chiara di chi si collega.

  2. Il progettista di sistema ha poca fiducia nella solidità dei browser Web esistenti. Se il browser di un utente viene violato, il cookie segreto può essere rubato e l'utente ha praticamente perso, per sempre. D'altra parte, se l'utente ha una smart card e that la smart card memorizza una chiave privata (che viene utilizzata in combinazione con un certificato client), un dirottamento completo del browser è ancora un grosso problema, ma è più contenuto: poiché la smart card commetterà seppuku onorevole invece di lasciare rivelare la preziosa chiave privata, la situazione può essere recuperata. Una volta eseguita la formattazione e la reinstallazione obbligatorie, le cose sono di nuovo sicure.

  3. Il sito Web non vuole solo autenticità, ma desidera anche non ripudio . Il non ripudio è un concetto legale che necessita di supporto da parte delle parti tecniche del sistema e che il supporto è firme digitali . Siamo al di fuori di ciò che offre SSL/TLS, qui. In nessun modo un'autenticazione client SSL/TLS può essere una prova che potrebbe essere utilizzata per risolvere alcuni conflitti legali tra l'utente e il server stesso (un server bancario non può mostrare la trascrizione della connessione e dire "vedi, quell'utente realmente mi ha chiesto di acquistare queste azioni a quel prezzo ", perché la banca avrebbe potuto facilmente fabbricare l'intera trascrizione). Per tali motivi, è necessario disporre dei certificati client e del codice lato client che utilizza il certificato per firmare i dati effettivi. Tuttavia, una volta eseguito il duro lavoro di rilascio dei certificati ai client, ha senso utilizzarli solo per HTTPS.

Nel caso comune di un server Web, nessuno di questi scenari si applica. Pertanto i certificati client non vengono utilizzati, poiché potrebbero sollevare problemi pratici senza aggiungere alcun valore aggiuntivo. Sarebbe una soluzione alla ricerca di un problema.

51
Thomas Pornin

Il motivo principale è che il 95% degli utenti di Internet non ha idea di cosa sia un certificato lato client, per non parlare di come usarlo. Alcuni utenti riescono a malapena a usare nomi utente e password e la maggior parte non si preoccupa ancora dell'autenticazione a due fattori. È anche una seccatura installare un certificato client su dispositivi separati (desktop, laptop, tablet, smartphone, ecc.) Per l'autenticazione su un singolo servizio.

Quindi, per un breve elenco:

  • Ignoranza. Le persone semplicemente non sanno cosa sono o perché sono utili.
  • Convenienza. Le persone non possono essere disturbate a configurare il proprio dispositivo per l'utilizzo dei certificati client.
  • Supporto. Se le persone oggi devono ancora telefonare al supporto tecnico quando dimenticano la password o non riescono ad accedere, puoi immaginare quante altre chiamate di supporto saranno necessarie se devono installare un certificato client ? Questo problema si moltiplica ulteriormente con la caduta della quota di mercato di Internet Explorer, quindi il personale deve essere addestrato per guidare gli utenti attraverso l'installazione su Internet Explorer, Firefox, Chrome, Opera, Safari, ecc. Oltre a vari dispositivi mobili.
  • Complessità. Per convalidare il certificato in relazione a un account utente è necessario un codice lato server aggiuntivo.
  • Prevalenza. Nessun sito principale li sta utilizzando in massa ancora, quindi nessun altro lo farà. Mi rendo conto che questo è un fermo-22, ma l'adozione della tecnologia lo è spesso.
  • Compiacenza. La maggior parte dei venditori presume che le password (o 2FA) siano abbastanza forti per i loro scopi, anche quando quei fornitori proteggono altamente sensibili/informazioni critiche come dati finanziari.

Quindi, mentre sarebbe bello vedere i certificati lato client su larga scala, non vedo davvero che ciò accada a meno che un evento serio non spinga i fornitori a farlo.

10
Polynomial

Il client sta tentando di raggiungere un server specifico, identificato nell'URL. Quindi il client deve autenticare il server.

D'altra parte, nella maggior parte degli usi di HTTPS, qualsiasi client può contattare il server. Il server non ha alcuna conoscenza precedente del client. Quindi non c'è nulla per cui il server autentichi il client. Il server vuole autenticare l'utente, non il computer client.

In un'impostazione Internet, il client potrebbe trovarsi dietro un proxy, un indirizzo IP dinamico, ecc. Non c'è nulla che il server potrebbe voler verificare. L'unico punto per autenticare il client sarebbe quello di registrare la sua identità per usi futuri, sia per scopi forensi o per rintracciare i client attraverso più connessioni. Poiché gli utenti possono connettersi da più macchine, non ha molto senso tracciare le macchine client. La registrazione delle identità dei client è solo marginalmente utile per identificare client o utenti malintenzionati dopo il fatto (è probabile che l'attaccante abbia generato un certificato che non fornisce alcuna informazione utile), non vale la pena spendere alcuno sforzo.

In un'impostazione Intranet, in cui solo i client noti devono connettersi al server, l'autenticazione client è utile e viene utilizzata.