Domanda:
Qualcuno sta usando i certificati del browser client?
StasM
2011-01-03 10:18:39 UTC
view on stackexchange narkive permalink

I certificati del browser del client sembrano essere un buon modo per proteggere i siti dagli intrusi: è impossibile indovinarli e dovrebbe essere più difficile da rubare. Ovviamente non risolvono tutti i problemi, ma aggiungono sicurezza.

Tuttavia, non ho riscontrato alcun sito pubblico che li utilizza. Ci sono siti che li utilizzano? C'è qualche difetto in loro che ne preclude l'utilizzo anche quando la sicurezza è importante o qualche altro motivo per cui viene utilizzato così poco?

StartSSL.com li utilizza - invece di creare un nome / password, genera un certificato client che viene utilizzato per il login [e deve essere sottoposto a backup dall'utente, altrimenti perdono l'accesso all'account!]. Almeno nel browser Chrome è stata un'esperienza sorprendentemente piacevole. Questo è l'unico esempio che ho incontrato personalmente fino ad oggi.
Sì, per i moderatori di un sito che gestisco.
Undici risposte:
#1
+20
nealmcb
2011-01-03 22:29:04 UTC
view on stackexchange narkive permalink

Le certificazioni lato client non hanno avuto un buon compromesso tra costi e benefici. Sono molto confusi per gli utenti, quindi i costi di supporto aumentano. E sono ancora solo bit e quindi "qualcosa che conosci" e sono vulnerabili a una serie di attacchi software al browser, allo schema di distribuzione, al phishing ecc.

Gli schemi di token hardware (authn a due fattori) sono meglio per il buon authn. Gli schemi Single Sign-On (SSO), potenzialmente federati e potenzialmente supportati da token hardware, risolvono più problemi e sono più facili da distribuire.

La gestione di molti certificati sarebbe molto più complicata per un utente di l'attuale spinoso problema di password multiple ei browser non offrono un buon supporto per la selezione del certificato giusto. E se un utente utilizza un unico certificato per molti siti, sussistono problemi di privacy poiché l'uso del certificato identifica l'utente.

Nel corso dei decenni, molti di noi hanno pensato che l'età della fine l'utente PK-crypto era proprio dietro l'angolo, specialmente quelli come me innamorati della bellezza di RSA. Si scopre solo che il modo in cui si è evoluto, l'help desk e i costi di sviluppo, le sottigliezze, le complessità e gli intrecci legali della PKI del mondo reale continuano a consumarne i benefici.

Le apparecchiature sembrano più costose dei bit, ma non se i bit non fanno il lavoro o se il loro uso efficace consuma la produttività.

Quasi nessuno usa nemmeno l'autenticazione a 2 fattori, ma almeno lì vedo il motivo: la distribuzione di token fisici ha dei costi. I certificati però non costano nulla.
Alcuni si stanno rivolgendo all'autenticazione software a 2 fattori, come la reimpostazione della password di Google invia una OTP al telefono quando si tenta di accedere da un computer che non riconosce e altri stanno esplorando la possibilità di utilizzare uno smartphone invece di un hardware token (per ridurre i costi).
#2
+18
AviD
2011-01-03 13:49:51 UTC
view on stackexchange narkive permalink

Uso i certificati del browser per una manciata di siti, ma come hai detto per lo più non siti pubblici.

La difficoltà principale nei certificati lato client è distribuirli . Cioè, come posso darti in modo sicuro il certificato "onnipotente" che ti garantirà l'accesso al mio sistema, se non ti conosco?
I sistemi aziendali sono più facili, ovviamente, così come i sistemi aperti a un piccola cerchia di partner. Ma la distribuzione delle chiavi è sempre un puzzle difficile da risolvere. È molto più difficile che condividere una password tra due parti, considerando gli aspetti della chiave privata e la protezione del certificato, ....

In realtà ci sono soluzioni a questo, ovviamente , e ne uso anche uno per un sito web "pubblico". (Capita di essere nel business dell'identità, quindi vale la pena per loro ...). Questa soluzione si basa sull'autenticazione primaria tramite password e, dopo essere stato completamente autenticato, ho la possibilità di scaricare il mio certificato, ammesso che io sappia cosa farne.
Non molto meglio, poiché il canale delle password è ancora aperto ... ma questo almeno mi dà la possibilità di cambiare la password in qualcosa di impossibile e inutilizzabile, e ho solo il CSC ....

Ma questo non è banale, e un po 'complesso da implementare correttamente. La distribuzione infastidirebbe ancora la maggior parte degli utenti.

Non deve essere onnipotente: puoi comunque chiedere una password, ad esempio. Puoi concedere l'accesso ad aree a bassa sicurezza solo con password e ad aree ad alta sicurezza solo con cert + password. Questo è solo un modello, ovviamente.
@StasM - Beh, sì, ma ancora una volta ciò aumenta solo la complessità dell'implementazione. E se lo fai, perché preoccuparti?
#3
+15
D.W.
2011-01-07 08:18:17 UTC
view on stackexchange narkive permalink

A quanto ho capito, ci sono numerosi problemi con l'utilizzo dei certificati client nella pratica. Ecco alcuni dei problemi che ho sentito:

  1. Ottenere i certificati del cliente. È un problema per gli utenti ottenere inizialmente un certificato cliente in primo luogo. Ovviamente, i siti non vogliono creare ostacoli inutili che gli utenti devono superare prima ancora di poter iniziare a utilizzare il loro sito. (Anche se il sito genera il certificato del client e lo fornisce al client non è un'operazione familiare per un utente, per non parlare del fatto che ha problemi di sicurezza, poiché idealmente, solo il client dovrebbe conoscere la chiave privata del client.) Browser moderni fornire modi per creare o importare chiavi private e certificati client, ma l'esperienza utente è orribile.

  2. Ho sentito che alcuni server apparentemente non supportano bene i certificati client (ad es. , http://osdir.com/ml/encryption.cryptlib/2005-09/msg00000.html).

  3. La mobilità è un problema. Nonostante tutti i loro problemi, le password sono molto portabili; i certificati client non lo sono. Anche se il cliente riesce a generare una chiave privata e ottiene un certificato client per essa, se vuole iniziare a utilizzare un secondo computer, dovrà fare una danza complicata e confusa per trasferire la chiave privata e il certificato al secondo computer. Se il loro primo computer muore (o subisce un guasto del disco rigido) e devono reinstallare il loro sistema operativo o acquistare un nuovo computer e se il client non ha eseguito il backup della loro chiave privata, non avranno modo di mettere la loro key e cert sul loro nuovo computer; sono piuttosto fottuti. Un sito può creare un metodo di autenticazione di backup in modo che gli utenti che hanno perso la chiave privata possano generare e inviare una nuova chiave privata, ma questo metodo di autenticazione di backup può facilmente diventare l'anello più debole della catena. Non importa quanto sia potente il tuo metodo di autenticazione principale, se il tuo metodo di backup è facilmente sconfitto.

  4. Non è chiaro se esiste un supporto sufficiente dai browser per i certificati client. Non so se tutti i vari browser disponibili (inclusi i browser mobili) supportano adeguatamente i certificati dei client.

  5. Il modello PKI è comunque abbastanza rotto. Il presupposto era che la CA avrebbe verificato l'identità dell'utente (ad esempio, il suo vero nome) prima di fornire loro un certificato client e il protocollo è stato progettato attorno a questo presupposto. Tuttavia, le CA di oggi non verificano realmente l'identità. Ciò crea una mancata corrispondenza tra i presupposti di progettazione e la realtà.

  6. Le certificazioni del cliente creano rischi per la privacy per gli utenti. In alcuni browser, consentono il monitoraggio degli utenti su più domini. (Tutti i browser assicurano che i cookie difendano attentamente da questa minaccia: solo il dominio che ha impostato il cookie può leggerlo. Tuttavia, i browser non incorporano protezioni simili per i certificati client SSL.) Non so se i browser moderni abbiano affrontato efficacemente questo problema problema, ma è un'area in cui i certificati client sono relativamente immaturi, per quanto ne so.

  7. Ci sono fastidiosi problemi tecnici, se il client genera e firma il proprio certificato client. Secondo il protocollo TLS, il server dovrebbe prima chiedere un elenco di CA che è disposto ad accettare; il cliente successivamente risponde con un certificato client emesso da quella CA, se ne ha uno. (Notare che ciò accade prima che il client abbia inviato una richiesta HTTP, qualsiasi cookie HTTP, un nome utente o qualsiasi altra informazione di identificazione.) Ciò significa che, se si desidera utilizzare certificati client emessi dal client (autofirmati), allora il il server deve conoscere il nome della CA che il client sta utilizzando prima che il client si autentichi o si identifichi. È complicato.

  8. Infine, la ciliegina sulla torta: i certificati client non risolvono il problema del phishing. Impediscono il furto della chiave privata del cliente, ma non di altre informazioni personali. I malintenzionati possono ancora creare un sito bancario falso (che scarta tutti i certificati dei clienti inviati). Il sito di phishing non apprenderà la chiave privata dell'utente, ma se l'utente pensa di essersi connesso al sito della banca reale, può digitare il numero di conto bancario, SSN, PIN, ecc., Rivelando tali informazioni all'aggressore.

Tutto ciò si traduce in scarsa usabilità e aumento dei costi di supporto (ad esempio, chiamate all'helpdesk). In breve, puoi utilizzare i certificati client, almeno in linea di principio; è solo che, in pratica, farlo è scomodo per tutti e l'usabilità fa schifo.

Più fondamentalmente, c'è un problema di gallina e uova: finché molti siti non iniziano a utilizzare i certificati dei client, i produttori di browser non lo faranno attribuire un'elevata priorità a rendere utilizzabili i certificati del cliente; e fino a quando i browser non renderanno utilizzabili i certificati client, i siti non li adotteranno. In altre parole, se vogliamo utilizzare i certificati client per risolvere il problema generale di autenticazione, dobbiamo entrambi convincere tutti i produttori di browser ad apportare modifiche importanti ai browser, e convincere i siti ad adottare nuove tecnologie. Nessun vantaggio va a nessuno finché tutte queste parti non apportano modifiche coordinate. Questo è un enorme ostacolo all'adozione.

Esistono soluzioni migliori per l'autenticazione sicura sul Web, che coinvolgono HTTPS, cookie permanenti protetti e ripristino basato sulla posta elettronica. Tuttavia questo va oltre lo scopo della tua domanda.

Ultimo commento: la sfida fondamentale nell'autenticazione web sicura è l'usabilità, l'usabilità, l'usabilità. Realizzare sistemi che funzionino bene per gli utenti - e che siano sicuri, se usati come è probabile che gli utenti normali li utilizzino - è molto impegnativo ed è tutto ciò che conta. Crypto è solo una piccola parte di questo problema.

L'elemento documentato nelle specifiche HTML5 (e supportato da molti browser prima) è un modo abbastanza utilizzabile per generare + installare coppie di chiavi sicure sul client. L'esperienza in Chrome è stata piuttosto fluida, almeno, e spero che anche FF.
L'elemento è deprecato in HTML5, secondo [W3C] (http://w3c.github.io/html/sec-forms.html#elementdef-keygen), [WHATWG] (https: //html.spec.whatwg.org / multipage / forms.html # the-keygen-element) e [MDN] (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen) ed è stato disabilitatoin Chrome a partire dalla versione 49.
#4
+7
bahamat
2011-01-03 12:24:59 UTC
view on stackexchange narkive permalink

Penso che principalmente non vengano utilizzati perché la persona media (cioè non tu dato che stai facendo questa domanda) non può capire il loro utilizzo. Ci sono alcuni siti commerciali che li utilizzano, ma di solito hanno uno scopo molto speciale o per l'automazione. Ad esempio, Oracle utilizza i certificati client per convalidare gli utenti finali con contratti di supporto validi per gli aggiornamenti dei pacchetti. Ma anche con utenti altamente tecnici che ottengono lo scambio di chiavi appropriato può essere difficile.

Detto questo, utilizzo i certificati del cliente per proteggere parti dei miei siti Web che lascio aperte al pubblico e penso che sono fantastici.

Capisco il tuo punto, ma tutto questo può essere fatto nel browser ... L'utente deve solo scaricare / fare doppio clic sul file e il gioco è fatto. Le estensioni del browser sono cose molto complesse, ma sono state rese semplici per l'utente, ad esempio.
Tutta questa roba "nel browser" richiede un bel po 'di codice sul lato server per essere implementata.
#5
+6
blowdart
2011-01-05 04:10:15 UTC
view on stackexchange narkive permalink

La carta d'identità nazionale estone è una smart card che contiene un certificato client incorporato su di essa. Puoi procurarti lettori di smart card e usarlo a casa per richiedere servizi governativi o autenticarti presso le principali banche estoni. Tutto ciò che l'utente vede è una richiesta di tessera / pin e la prossima cosa che sa di essere autenticato.

#6
+5
Martijn Heemels
2011-01-04 06:16:59 UTC
view on stackexchange narkive permalink

Uno dei nostri clienti utilizza i certificati del cliente per autenticare i sistemi di chioschi touch-screen. I sistemi vengono distribuiti ai rivenditori e ciascuno ottiene il proprio certificato di root CA installato oltre a un certificato client univoco.

Il certificato client viene utilizzato per autenticare il sistema del chiosco sul server web, senza richiedere al rivenditore di eseguire autenticazione manuale all'avvio del dispositivo. Se un singolo sistema deve essere escluso, è facile per il nostro cliente revocare il certificato.

Vedi, qui la distribuzione è curata, è banale rispetto alla consegna dei chioschi ... Anche se metterei in dubbio la sicurezza di questo sistema, dopo che tutti gli utenti anonimi possono accedere direttamente al chiosco - e forse "prendere in prestito" il certificato?
È vero, AviD. Ovviamente il chiosco dovrebbe essere adeguatamente rinforzato per impedire quel tipo di accesso. Se un certificato viene rubato, può essere revocato individualmente dalla CA poiché tale chiosco deve essere considerato compromesso. In questo caso le informazioni sul webserver non sono abbastanza critiche da richiedere misure aggiuntive, quindi il client-cert è fondamentalmente un'alternativa a una password.
#7
+4
Jcs
2011-01-03 22:18:25 UTC
view on stackexchange narkive permalink

Il ministro dell'Economia francese ha pubblicato un sito web pubblico per la gestione fiscale (pagamento delle tasse in linea, informazioni sulle scadenze, download di moduli ...) che utilizza il certificato SSL per l'autenticazione dell'utente. La registrazione dell'utente (questo ruolo è attribuito a una Autorità di registrazione in PKI) che è stata indicata da AviD ♦ come la principale difficoltà in un tale progetto, è stata risolta poiché questa amministrazione dispone già di informazioni sufficienti per identificare i contribuenti.

Il problema non è solo l'identificazione iniziale, la sua distribuzione dei certificati.
Sì, non ero chiaro. Intendevo che l'amministrazione è in grado di garantire che l'identità del richiedente del certificato (ovvero il titolare privato) corrisponda e l'identità dichiarata. Tecnicamente c'è un numero privato univoco sulla ricevuta di pagamento delle tasse (dell'anno precedente) utilizzato come segreto condiviso durante il processo di generazione del certificato.
Veramente? considerano questo "numero unico di pagamento delle tasse" un segreto protetto? Humph ... Beh, immagino che non sia peggio che gli Stati Uniti considerino SSN una forma di identificazione sicura ...
#8
+1
goodguys_activate
2012-12-29 05:23:47 UTC
view on stackexchange narkive permalink

Una variazione dei certificati del browser viene utilizzata nel protocollo ActiveSync basato su HTTP / S.

Diversi amministratori di posta elettronica utilizzano certificati per autenticare un dispositivo mobile in modo che l'email mobile non smetta improvvisamente di funzionare quando l'utente cambia la password.

#9
+1
Serge Ballesta
2016-04-29 14:39:04 UTC
view on stackexchange narkive permalink

I certificati client hanno la migliore qualità per l'autenticazione. Ma a causa di un problema con l'uovo e la gallina gli utenti non hanno motivo di acquisire un certificato serio (costa denaro e tempo perché la consegna dovrebbe essere un'operazione faccia a faccia) perché pochi siti li usano e gli amministratori del sito non hanno motivo di supportarli attivamente da allora i loro utenti generalmente non hanno certificati.

I sistemi aziendali sono diversi perché se i requisiti di sicurezza sono sufficientemente elevati, il costo globale di un'infrastruttura PKI è perfettamente accettabile.

Ma quando ricordi cosa il costo totale reale e la procedura per una carta d'identità nazionale (senza parlare di un passaporto), l'aggiunta di un certificato stabilito da un'amministrazione nazionale non aggiungerebbe molto e risolverebbe bene tutte le questioni di autenticazione con siti istituzionali come amministrazioni, banche, ... Ovviamente non lo userei per siti di commercianti o forum poco controllati

#10
  0
Totoro53
2016-04-29 14:02:29 UTC
view on stackexchange narkive permalink

Lavoro allo sviluppo di un sito che offre l'autenticazione tramite smart card. L'utente collega un lettore di schede USB, va al sito e quando vuole accedere inserisce la scheda e fornisce un PIN. Il problema è che il sistema utilizza un'applet Java e queste applet non sono più supportate da Chrome o da MS Edge. È in fase di sviluppo un nuovo middleware che non utilizza applet Java ed è una corsa contro il tempo poiché possiamo vedere tutti i principali browser che impediscono alle applet Java di interagire con l'hardware del tuo PC in futuro.

#11
  0
Archimedes Trajano
2018-03-21 22:22:39 UTC
view on stackexchange narkive permalink

Se espandiamo l'ambito OP per andare oltre il browser. I certificati client possono essere utilizzati anche nel contesto non browser. Ad esempio Docker utilizza TLS e certificati client per proteggere le loro connessioni tra un client Docker remoto ai propri daemon.

Questo dovrebbe comunque essere gestito, ma non ha bisogno di passare attraverso una CA completa, può essere una CA interna dell'azienda per gestire tutti i certificati utilizzati dalle macchine.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 2.0 con cui è distribuito.
Loading...