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

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

Per la maggior parte dei siti Web, la nozione interessante è continuità . A loro non importa davvero chi è connesso; infatti, il punto di un sito Web deve essere leggibile da tutti . Il tipo di autenticità che un sito Web desidera raggiungere è quello di assicurarsi che due richieste successive siano realmente dallo stesso cliente (chiunque sia quel cliente). 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 l'intromissione con quel framework simile a un film è ciò che l'attaccante cerca. L'utente e i progettisti del sito Web pensano in termini di sessioni e l'utente malintenzionato vuole dirottare la sessione.

Questa autenticità è ottenuta con 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 (è la "stretta di mano abbreviata" descritta nella sezione 7.3 del SSL / TLS standard ).
• 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, nel vederlo tornare nelle richieste successive, il server è convinto che le richieste provengano dallo stesso utente.

Il cookie è sufficiente per garantire la continuità.

Quale valore aggiuntivo aggiungerebbero i certificati client? Beh, non molto. I certificati sono un modo per distribuire associazioni di chiavi / nomi. 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 accessibile ai cittadini, ma solo dopo una corretta autenticazione, ad es. un sistema elettorale online. Ciò che rende il cittadino, con il suo nome e data di nascita definiti, è gestito dallo Stato in generale, ma non è la stessa parte di quello che gestisce il servizio. I certificati client sono quindi un modo per trasportare l'autenticazione dal PKI che ha rilasciato il certificato al cittadino, al sistema elettorale online che non ha il diritto di dire chi viene nominato cosa, ma deve comunque tenere un registro chiaro di chi si connette. / p>

2. Il progettista del sistema ha poca fiducia nella robustezza dei browser Web esistenti. Se il browser di un utente viene dirottato, 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 quella smart card memorizza una chiave privata (che viene utilizzata in combinazione con un certificato client), allora un completo dirottamento del browser è ancora un grosso problema , ma è più contenuto : poiché la smart card commetterà un seppuku onorevole invece di lasciare rivelare la preziosa chiave privata, la situazione potrà essere recuperata da. Una volta eseguito il formato e la reinstallazione obbligatori, le cose sono sicure ancora una volta.

3. Il sito Web non vuole solo autenticità, ma desidera anche ottenere non ripudio . Il non ripudio è un concetto legale che richiede un certo supporto dalle parti tecniche del sistema e tale supporto è firme digitali . Siamo al di fuori di ciò che fornisce SSL / TLS, qui. In nessun modo l'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 davvero mi ha chiesto di comprare queste azioni a quel prezzo ", perché la banca avrebbe potuto facilmente fabbricare l'intero trascritto). Per tali cose, è necessario un certificato client e un 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 per HTTPS.

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

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

Quindi, per una lista veloce:

• Ignoranza. Le persone semplicemente non sanno cosa sono o perché sono utili.
• Praticità. Le persone non possono essere disturbate a configurare il proprio dispositivo per l'utilizzo dei certificati client.
• Supporto. Se le persone 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 a causa della caduta della quota di mercato di Internet Explorer, quindi il personale deve essere addestrato per guidare gli utenti attraverso l'installazione su IE, Firefox, Chrome, Opera, Safari, ecc. Più vari dispositivi mobili.
• Complessità. È richiesto un codice lato server aggiuntivo per convalidare il certificato in relazione a un account utente.
• Prevalenza. Nessun sito principale li sta ancora utilizzando en-mass , quindi nessun altro lo farà. Mi rendo conto che questo è un catch-22, ma l'adozione della tecnologia è spesso.
• Complacency. La maggior parte dei venditori ritiene che le password (o 2FA) siano sufficientemente efficaci per i loro scopi, anche quando tali fornitori proteggono informazioni sensibili / critiche come i 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 venditori a farlo.

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 preliminare del client. Quindi non c'è nulla per il server per autenticare il client contro. Il server desidera autenticare l'utente, non il computer client.

In un'impostazione Internet, il client potrebbe trovarsi dietro un proxy, su un indirizzo IP dinamico, ecc. Non c'è nulla che il server possa voler verificare. L'unico punto di autenticazione del client sarebbe quello di registrare la sua identità per usi futuri, sia per scopi legali che per tracciare i client attraverso più connessioni. Dal momento che gli utenti possono connettersi da più macchine, non ha molto senso rintracciare i computer client. La registrazione delle identità dei client è utile solo marginalmente per identificare i client o gli utenti malintenzionati dopo il fatto (è probabile che l'autore dell'attacco abbia generato un certificato che non fornisce informazioni utili), 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.

In casi come Gmail, Yahoo e altre app Web che utilizzano la PKI per autenticare i server, l'autenticazione del client non viene eseguita utilizzando i certificati, ma utilizza invece un'autenticazione più semplice come le password di utente / nome. Pensaci. Il tuo browser può memorizzare il numero x di certificati per le varie CA e i siti Web disponibili. Ma Gmail può conservare i certificati per i suoi milioni di utenti? Semplicemente non è scalabile.

Questa è una risposta molto semplificata sul perché i certificati client non vengono utilizzati. Tuttavia, quando si SSH in un server, i certificati client sono / forse utilizzati.