Esiste un modo per controllare i certificati nell'archivio principale di un cliente?

0

Quando un client si connette a un server web, esiste un modo per verificare quali CA radice ha il client?

Modifica: potrei usare JavaScript per inviare una richiesta GET o POST al server, fornendo un certificato che la CA che sto controllando deve firmare? Se la connessione fallisce, saprò che la CA radice non è installata sul client.

    
posta Fred Heinecke 19.03.2015 - 00:12
fonte

3 risposte

1

No, il server web non può controllare di vedere tutte le CA che il client ha installato.

Se si ha accesso al computer client, è possibile controllare visualizzando l'archivio Autorità di certificazione fonti attendibili.

    
risposta data 19.03.2015 - 03:40
fonte
1

In generale, la natura stessa di PKI (e una buona manutenzione del sistema) dovrebbe impedire che ciò costituisca un rischio per la sicurezza. Ma personalmente, non sono sicuro che vorrei davvero solo un sito Web per poter enumerare la mia lista di CA di fiducia. Questo sembra un buon modo per scovare i sistemi vulnerabili agli attacchi usando roba come certificati DigiNotar o certificati da altri compromessi della CA principale.

Considera questo scenario:

Un utente malintenzionato invia una e-mail di phishing a un gruppo di utenti con un collegamento ad un sito sotto il controllo dell'aggressore. Il sito stesso è generalmente benigno e ha un valore minore di intrattenimento. Ma quando gli utenti visitano il sito, il server registra la visita e la associa con l'indirizzo e-mail dell'utente. Il server quindi enumera l'elenco di CA attendibili per gli utenti e registra se c'è qualche CA di interesse per l'autore dell'attacco all'interno di tale elenco.

Ora, l'hacker sa (tra le altre cose):

  1. L'account e-mail dell'utente è attivo e l'utente malintenzionato può creare un messaggio e-mail in modo che l'utente sia incline ad aprirlo e fare clic su un collegamento.
  2. Il browser dell'utente si fida di una o più CA principali che l'autore dell'attacco ha ritenuto interessanti.

L'autore dell'attacco potrebbe aver contrassegnato tali CA radice come interessanti per qualsiasi numero di motivi. Ecco un paio:

  • L'attaccante al momento ha il controllo sulla CA radice, in modo che possa farlo firmare certificati arbitrari generati dall'hacker.
  • L'autore dell'attacco ha già alcuni certificati di alto valore firmati dalla CA principale (tramite controllo precedente o trucco).

Ora l'attaccante ha un gruppo di vittime che può ragionevolmente aspettarsi essere suscettibili agli attacchi di phishing che indirizzano l'utente a un sito Web sotto il controllo dell'attaccante. Questo sito Web potrebbe presentarsi come sito bancario o qualsiasi altro sito in cui l'utente potrebbe essere disposto a fornire autenticatori di alto valore o altre informazioni utili. L'utente potrebbe fidarsi del sito Web in questo modo, poiché l'utente malintenzionato sa che il browser si fiderà del suo certificato poiché è firmato da una "CA radice affidabile".

Dal momento che il primo round di e-mail potrebbe puntare a un sito relativamente benigno (ovvero: il sito non serve effettivamente malware o rubare informazioni sugli utenti), è meno probabile che qualcuno lo noti o lo riferisca e l'attaccante potrebbe probabilmente operare liberamente mentre raccoglie i dati per il secondo round.

Senza le informazioni del primo turno, le e-mail del secondo turno dovrebbero andare in un pool molto più ampio ed è molto più probabile che catturino l'attenzione indesiderata a causa degli utenti che sono più inclini a segnalare le e-mail degli aggressori che per seguire i suoi collegamenti, o gli utenti i cui browser non si fidano della CA radice che ha firmato il certificato dell'attaccante.

La natura dell'infrastruttura PKI dovrebbe generalmente impedire che l'enumerazione della CA radice affidabile sia un problema, poiché l'autore dell'attacco avrà comunque bisogno della chiave privata della CA principale o di un certificato firmato dalla CA principale, affinché le informazioni siano davvero valide. Tuttavia, come esemplificato da DigiNotar e altri, questo non è affatto al di là del regno della possibilità.

L'aggiornamento del sistema inibisce anche questi attacchi perché gli aggiornamenti del sistema operativo e del software includono di routine gli aggiornamenti degli archivi CA di Trusted Root. Ciò renderà le CA root-root conosciute e compromesse non valide per il tuo browser, quindi l'utente malintenzionato non potrà utilizzare i suoi certificati per rendere il loro sito attendibile.

Tuttavia, rimane una minaccia per gli utenti che non hanno ancora aggiornato l'elenco delle CA radice affidabili in seguito a un recente compromesso. Anche ora, (2015) probabilmente ci sono un certo numero di sistemi che non hanno ancora ricevuto aggiornamenti per rimuovere DigiNotar (2011), a causa delle pratiche di manutenzione lassista.

Quindi, mentre le opportune precauzioni di sicurezza e la manutenzione del sistema impediscono che l'enumerazione CA Trusted Root sia di gran valore per un utente malintenzionato nella maggior parte degli scenari, non è ancora qualcosa che il tuo browser deve semplicemente consegnare a chiunque.

Tutto ciò che ho detto, non so personalmente se ci sia o non sia un modo per farlo, mi sembra una cattiva idea per me.

    
risposta data 19.03.2015 - 15:58
fonte
0

Edit: Could I use JavaScript to send a GET or POST request to the server, providing a certificate that the CA I'm checking for has to sign? If the connection fails I'll know that the root CA isn't installed on the client.

Questa è probabilmente la cosa migliore che potresti fare. È ancora possibile ottenere falsi negativi se l'handshake TLS non riesce per qualche altro motivo (il che è improbabile se si utilizza lo stesso server con la stessa configurazione per tutto il tempo). Riceverai informazioni errate se il client si trova dietro qualche dispositivo / proxy di intercettazione TLS (come firewall o il famigerato SuperFish ), perché in questo modo si otterranno tutte le CA accettate da questo dispositivo / proxy e non dal browser stesso.

    
risposta data 19.03.2015 - 06:19
fonte