it-swarm.dev

Quanto è fattibile hackerare una CA? Quali certificati radice attendibili predefiniti dovrei rimuovere?

Questa domanda è stata rivista e chiarita in modo significativo dalla versione originale.

Se esaminiamo ogni certificato attendibile nel mio archivio radice attendibile, quanto dovrei fidarmi di loro?

Quali fattori devono essere presi in considerazione quando valuto la fiducia di ciascuna CA principale per la potenziale rimozione dal mio negozio locale?

Ulteriori informazioni:
Se un'autorità di certificazione emette un certificato a una parte convalidata in modo errato, ciò causa tutte le macchine che ritengono tale CA vulnerabile agli attacchi MITM. Di conseguenza, tutte le CA convalidano rigorosamente il richiedente di una determinata richiesta di certificato SSL per garantire l'integrità della propria catena CS.

Tuttavia, gran parte di questo processo di verifica della CA è soggetto all'intervento umano e offre l'opportunità di rilasciare un certificato alla parte sbagliata. Ciò può essere fatto per errore dell'operatore CA, richieste del governo o forse per coercizione (bustarella) di un operatore CA.

Vorrei saperne di più su quali CA predefinite hanno maggiori probabilità di emettere certificati per la parte sbagliata. Ho intenzione di utilizzare queste informazioni per consigliare agli utenti di rimuovere quella CA dal loro Trusted Cert Store

Esempi:
Supponiamo che il governo che controlla una determinata CA desideri assumere l'identità di Microsoft.com e richieda un'eccezione al processo di verifica della CA. Tale governo richiede quindi il mantenimento della segretezza di questa eccezione. La coppia di chiavi generata verrebbe quindi utilizzata in un attacco MITM.

Trust predefinito di Windows Azure

Windows Azure supporta 275 CA come mostrato in il seguente collegamento . A seconda dell'uso di una determinata CA, alcune di queste CA possono aumentare la superficie di un determinato attacco. In effetti questo potrebbe essere tecnicamente necessario per far funzionare correttamente alcune applicazioni.

Amazon Default Trust

(non disponibile) Si prega di condividere i collegamenti all'elenco CA predefinito di Amazon, Google e VMWare se li si incontra.

Mozilla

È disponibile un elenco di tutti i certificati e le dichiarazioni di verifica .

Apple iOS

Elenco di tutti certificati radice iPhone come indicato in questo # WWDC2017. Video

84

Aggiornamento 5 Il problema alla radice (heh) con il modello CA è che nella pratica generale qualsiasi CA può emettere certificati per qualsiasi dominio, quindi sei vulnerabile al collegamento più debole. Di chi ti puoi fidare, dubito che l'elenco sia molto lungo, dal momento che la posta in gioco è alta e la sicurezza è difficile. Raccomando il post di Christopher Soghoian sull'argomento, che chiarisce i vari approcci che i governi di tutto il mondo hanno usato per ottenere l'accesso ai dati degli utenti privati, sia richiedendoli direttamente da aziende che gestiscono servizi cloud, tramite intercettazione telefonica o sempre più spesso tramite coercizione CA o hack: leggera paranoia: le forze che hanno portato all'hack di DigiNotar .

Qui fornisco alcuni dettagli e finisco con i collegamenti ad alcune potenziali correzioni.

Nel 2009 Etisalat (posseduto al 60% dal governo degli Emirati Arabi Uniti) ha lanciato una patch BlackBerry dall'aspetto innocuo che ha inserito spyware nei dispositivi RIM, consentendo il monitoraggio della posta elettronica, quindi difficilmente può essere considerato affidabile. Ma è in molti elenchi di CA affidabili: http://arstechnica.com/business/news/2009/07/mobile-carrier-rolls-out-spyware-as-a-3g-update.ars

Aggiornamento 1 Vedi anche un esempio di attacco riuscito, presumibilmente da un iraniano di nome ComodoHacker , contro Comodo: Certificati SSL non autorizzati ("caso comodogate") - F-Secure Weblog . F-Secure osserva che Mozilla include certificati emessi da autorità competenti in Cina, Israele, Bermuda, Sudafrica, Estonia, Romania, Slovacchia, Spagna, Norvegia, Colombia, Francia, Taiwan, Regno Unito, Paesi Bassi, Turchia, Stati Uniti, Hong Kong, Giappone , Ungheria, Germania e Svizzera.

La Tunisia è un altro paese che gestisce una CA ampiamente fidata, e c'è anche una buona documentazione delle azioni del loro governo per invadere la privacy: La storia interna di come Facebook ha reagito agli hack tunisini - Alexis Madrigal - Technology - The Atlantic

Mozilla rileva un'altra pratica discutibile a cui prestare attenzione: le autorità di certificazione che consentono a un partner RA di emettere certificati direttamente dalla radice, anziché tramite un intermediario: Comodo Certificate Issue - Follow Up at Mozilla Security Blog .
Vedi anche maggiori dettagli, inclusa la speculazione sulla rivendicazione di responsabilità da parte di un hacker iraniano solitario Browser Web e Comodo divulgano un attacco dell'autorità di certificazione riuscita, forse dall'Iran | Freedom to Tinker

Aggiornamento 3 : Un altro attacco riuscito apparentemente anche da ComodoHacker è stato contro il DigiNotar CA. Il loro sito Web è stato compromesso a partire dal 2009, ma questo non è stato notato fino a quando DigiNotar non è stato utilizzato anche nel 2011 dagli iraniani per firmare certificati falsi per i siti Web di Google, Yahoo !, Mozilla, WordPress e Il progetto Tor. DigiNotar non ha rivelato la sua conoscenza dell'intrusione nel suo sito per oltre un mese. Vedi di più su DigiNotar Hack evidenzia i guasti critici del nostro modello di sicurezza Web SSL | Freedom to Tinker .

Immagino che la gamma di vulnerabilità di varie CA differisca piuttosto ampiamente, così come la loro utilità. Quindi suggerirei di rifocalizzare la tua strategia. Quando puoi restringerlo a risorse specifiche che stai cercando di proteggere, elimina tutte le CA ad eccezione di quelle necessarie per l'utilizzo di tali risorse. Altrimenti, considera di eliminare le CA che ritieni più vulnerabili a coloro che si prendono cura dei tuoi beni, o meno popolari, solo per ridurre la superficie di attacco. Ma accetta il fatto che rimarrai vulnerabile ad attacchi sofisticati anche contro le CA più popolari e attente.

Aggiornamento 2 : C'è un ottimo post sulla correzione della nostra pericolosa infrastruttura CA su Freedom to Tinker: Costruire una migliore infrastruttura CA

Parla di queste innovazioni:

Aggiornamento 4 Uno dei nostri post sul blog sulla sicurezza IT nell'agosto 2011 copre anche il caso del passaggio a DNSSEC: no sguardo basato sul rischio alla correzione il problema dell'autorità di certificazione "Stack Exchange Security Blog

Aggiornamento 6 Diverse autorità di certificazione sono state sorprese a violare le regole. Ciò include l'agenzia di cyberdefense francese (ANSSI) e Trustwave, ognuna delle quali era collegata allo spoofing dei certificati digitali .

Aggiornamento 7 Ancora un'altra serie di "certificati errati", tramite il controllore indiano delle autorità di certificazione (India CCA) nel 2014: Google Online Security Blog: mantenimento della sicurezza dei certificati digitali

Vedi anche la domanda su Trasparenza dei certificati che sembra un approccio utile alla scoperta di certificati non validi e violazioni delle norme in precedenza.

64
nealmcb

Come scrisse Matt Blaze, le autorità di certificazione ti proteggono da chiunque non voglia prendere denaro. Ciò dovrebbe dirti qualcosa su dove si trovano gli incentivi della CA e alcuni potenziali rischi nell'accordo.

38
D.W.

Temo che la breve risposta a questa domanda sia impossibile da sapere, per quanto posso vedere. Esiste un gran numero di CA predefinite installate nei browser più comuni e valutare la probabilità che siano "affidabili" in termini di rilascio di certificati a organizzazioni governative o di altro tipo è difficile.

Se una CA diventasse inaffidabile, verrebbe probabilmente rimosso dagli elenchi di installazione predefiniti del browser (per @xce di seguito, Diginotar è un buon esempio qui e anche Digicert)

Oltre all'organizzazione che fornisce volontariamente certificati, esiste il rischio che possano fornire certificati senza effettuare adeguati controlli di sicurezza sul richiedente. A Defcon un paio d'anni fa c'erano diverse presentazioni su questo tema di poter ottenere certificati senza autorizzazione.

Se questa è una preoccupazione significativa, l'unico modo in cui riesco a pensare sarebbe quello di creare una lista bianca di CA che hai esaminato e che sono a tuo agio con la sicurezza fornita. Ovviamente questo non funzionerebbe per l'accesso a Internet in quanto probabilmente finiresti per rimuovere le CA che hanno problemi con i Certs sui siti che vorresti usare.

18
Rory McCune

2 esempi che vanno al cuore di ciò che devi sapere, ma non di ciò che stai esplicitamente chiedendo:

  • Diversi anni fa (2006, o forse fine del 2005) si è verificato un incidente abbastanza ben pubblicizzato di phishing SSL: un sito Web di una banca fasulla ha ricevuto un certificato SSL legittimo (da GeoTrust, credo), per un errore di ortografia del sito di una banca regionale. (Aggiornamento: trovato questo link storico - l'indirizzo era per il nome completo della banca anziché l'acronimo abbreviato). Da allora, ci sono stati altri casi di phishing SSL .... Il punto è che è possibile ottenere un certificato senza ricorrere alla "coercizione".
  • La recente novella Stuxnet fa affidamento, tra le altre tattiche, sui certificati rubati. Questi sono stati "presi in prestito" da produttori di driver di terze parti e, poiché erano "affidabili", potevano essere utilizzati in modo improprio per piantare il malware.

Quindi, naturalmente, ci sono scenari software in cui la CA non viene nemmeno chiamata in uso - ad es. con client spessi che chiamano Web Services, che non si preoccupano di convalidare il certificato del server ....

Il mio punto è che se sei preoccupato per MITM su SSL, il più delle volte, non è la coercizione governativa che dovrebbe preoccuparti. Di solito ci sono modi più facili e più accessibili.
Mi oppongo persino al fatto che "Trusted Certs" venga chiamato "Trusted" ... Solo perché so chi sei, non significa che dovrei fidarmi di te ... e non significa che dovrei fidarmi che tu sappia chi qualcuno else lo è.

Per non parlare del fatto che se si rimuovono certificati root standard dal negozio di fiducia, molti siti su Internet non funzioneranno come previsto.

D'altra parte, se hai a che fare con un server/dispositivo che non ha non bisogno di funzionalità di navigazione generali, ma sta comunicando con un server specifico (o set di server), rimuovi definitivamente [~ # ~] tutti i certificati root [~ # ~] , tranne una whitelist di quelli che ti servono.
E se vai con la tua CA interna, ancora meglio ....

11
AviD

Ogni CA pubblica una dichiarazione di pratica del certificato che descrive come proteggono le proprie chiavi e convalida le richieste di certificati prima di emetterle. Un URL per l'ubicazione di questo documento è generalmente incorporato in ciascun certificato emesso dalla CA. Supponendo che la CA in questione segua effettivamente questo documento politico, dovrebbe fornire un'indicazione delle lunghezze a cui vanno per accertare la validità dell'entità che richiede i certificati. Cerca le dichiarazioni secondo cui proteggono le loro chiavi di firma CA utilizzando i moduli di sicurezza hardware o i moduli crittografici per proteggere le chiavi di firma, l'autenticazione a più fattori e l'autorizzazione basata sul quorum per firmare certificati, ecc. Questi metodi di protezione rendono molto più difficile e costoso per una terza parte canaglia per rubare le chiavi di firma.

L'enorme elenco di CA affidabili (il mio portachiavi di root del sistema Mac ha 175) è lì per tua comodità, per rendere il sistema HTTPS utilizzabile per te e per tutti gli abitanti del pianeta che non pongono queste domande. Naturalmente, è possibile eliminare tutte le CA da questo elenco a meno che non si siano verificate personalmente le loro pratiche. Per un sistema chiuso, in cui si controllano tutti gli endpoint e si dispone di un numero limitato di parti affidabili, è possibile farlo. Il sistema di controllo della versione di Subversion non include alcun certificato radice attendibile, ma puoi aggiungere il tuo ad ogni client. Per il Web in generale, l'unico modo che abbiamo trovato per renderlo utilizzabile è quello di avere una parte fidata fuori banda (la società che fornisce il sistema operativo o il browser, qualunque cosa tu possa pensare di loro) fornisca un elenco di fidati certificati che consentono di connettersi praticamente a qualsiasi server abilitato SSL nel mondo.

Hai davvero bisogno di tutti quei certificati nella tua lista di fiducia? Probabilmente no. Ma il tuo fornitore di sistema operativo/browser non può prevedere (e non dovrebbe controllare) con chi vuoi fare affari, quindi li include tutti. Il problema con l'elenco di grandi dimensioni è che hai CA di tutti i piumaggi, con tutti i tipi di metodi di verifica, di tutte le giurisdizioni, trattati esattamente allo stesso modo. Non tutte le CA agiscono allo stesso modo: abbiamo riscontrato casi di credenziali di accesso del rivenditore compromesse e persino chiavi della CA compromesse. Alcune CA richiedono un certificato di incorporazione e la promessa del tuo primogenito, altre semplicemente verificano che tu possa ricevere e-mail sul dominio per il quale stai richiedendo un certificato. Eppure ogni CA è trattata esattamente allo stesso modo dal tuo browser.

Una linea di difesa contro i certificati non autorizzati per lo stesso nome comune sarebbe quella di memorizzare nella cache il certificato originale sul client: se un certificato diverso da una CA diversa si presenta improvvisamente, questo dovrebbe essere motivo di preoccupazione. Non so come i browser di oggi trattano questo caso e sono troppo pigro per scoprirlo.

9
Sander Temme

Questo tipo di discussione mi ricorda sempre questo bug di Mozilla che richiede l'inclusione di una nuova CA. Abbastanza divertente, ma piuttosto perspicace.

4
Steve Dispensa

Quando cerchi quale certificato rimuovere in un PC Windows, devi prima assicurarti di non rimuovere i certificati richiesti dal sistema. Se si tenta di farlo, verrà visualizzato il seguente messaggio di errore

error- you're deleting a system cert!!

Questo è l'URL con un elenco di certificati che non devono mai essere eliminati da un sistema Windows http://support.Microsoft.com/?id=293781

Successivamente dovresti considerare di rimuovere (testare la rimozione di) certificati intermedi, poiché esistono solo " solo per motivi legacy ".

Quando si valuta la rimozione di tutti i certificati rimanenti, considerare che Microsoft Root Certificate Program richiede che la CA superi uno di questi standard di controllo:

  • ETSI 102 042
  • ETSI 101 456
  • WebTrust per le autorità di certificazione
  • Audit di prontezza WebTrust EV
  • ISO 21188 (notare che non accettano ISO 27001)

Se stai rimuovendo Certs da un browser non MSFT (IE), potresti voler rivedere queste linee guida sulla qualità della CA .

Restrizioni

Il programma ha anche audit aggiuntivi che si applicano a ciò che è l'utilizzo chiave. L'utilizzo delle chiavi è limitato a quanto segue:

  • Autenticazione server (SSL) = 1.3.6.1.5.5.7.3.1

  • Autenticazione client (SSL) = 1.3.6.1.5.5.7.3.2

  • EKU posta elettronica sicura (SMIME) = 1.3.6.1.5.5.7.3.4

  • Firma del codice EKU = 1.3.6.1.5.5.7.3.3

  • Timestamp EKU = 1.3.6.1.5.5.7.3.8

  • EKU OCSP = 1.3.6.1.5.5.7.3.9

  • Crittografia file system EKU = 1.3.6.1.4.1.311.10.3.4

  • IPSec (Tunnel, User) EKU = 1.3.6.1.5.5.7.3.6, 1.3.6.1.5.5.7.3.7

Usi chiave vietati

I seguenti usi chiave sono vietati dal programma:

  • Accesso con smart card Questo è uno scenario aziendale, poiché è necessaria la distribuzione di Active Directory e la radice deve essere aggiunta all'archivio NTAuth in Active Directory. Vedere il seguente articolo KB per i dettagli. http://support.Microsoft.com/default.aspx?scid=kb;en-us;Q281245

  • Diritti digitali Questa EKU è obsoleta. Windows Media DRM utilizza il proprio formato XML per le licenze e non utilizza X.509.

  • Subordinazione qualificata Questa EKU è obsoleta ed è ignorata da Windows.

  • Scenario CA Enterprise di recupero chiave.

  • Ripristino di file Questa EKU è obsoleta e viene ignorata da Windows Encrypting File System (EFS).

  • Tutte le politiche applicative Non possiamo concedere "tutti gli utilizzi" poiché ciò ammette necessariamente EKU solo aziendali e altre EKU inaccettabili.

  • Replica dell'email del servizio directory Scenario aziendale

  • Agente di richiesta certificato

  • Scenario CA Enterprise

  • Scenario CA Enterprise agente di recupero chiavi

  • Certificato di crittografia CA.

  • Scenario CA Enterprise

Criteri di accettazione

Inoltre, devono essere soddisfatti i seguenti criteri prima di aggiungere un CA generico o CA alla radice:

  1. La CA deve fornire le informazioni richieste di seguito (vedere Passaggio 1. Contattare Microsoft ) e ricevere l'approvazione preliminare per l'adesione al Programma.

  2. La CA deve fornire un certificato di prova emesso dal certificato radice della CA a scopo di prova. Facoltativamente, una CA può fornire a Microsoft un URL di un server accessibile pubblicamente in cui è possibile verificare i certificati emessi dal loro certificato radice. (Vedi FAQ per i dettagli)

  3. La CA deve completare un Accordo della CA Microsoft. L'accordo verrà fornito solo dopo aver completato il passaggio 1 della procedura di domanda e aver ricevuto l'approvazione preliminare della domanda.

  4. I certificati di root devono essere conformi alla sezione Requisiti tecnici di seguito. In particolare, è richiesta una dimensione minima della chiave crittografica del modulo RSA 2048 bit per qualsiasi root e tutte le CA di emissione. Microsoft non accetterà più certificati root con modulo RSA 1024 bit di qualsiasi scadenza. Preferiamo che le nuove radici siano valide per almeno 8 anni dalla data di invio, ma scadano prima dell'anno 2030, specialmente se hanno un modulo RSA a 2048 bit.

  5. I certificati emessi da un certificato radice devono supportare l'estensione del punto di distribuzione CRL. Il punto di distribuzione CRL deve puntare a una posizione accessibile al pubblico.

  6. L'autorità di certificazione deve disporre di una politica di revoca documentata e deve essere in grado di revocare qualsiasi certificato emesso.

  7. L'autorità di certificazione deve completare un controllo e inviare i risultati del controllo a Microsoft ogni dodici (12) mesi. L'audit deve coprire l'intera gerarchia PKI che sarà abilitata da Microsoft tramite l'assegnazione di Extended Key Usages (EKU). Tutti gli usi dei certificati che abilitiamo devono essere controllati periodicamente. Il rapporto di audit deve documentare l'intero ambito della gerarchia PKI, incluso qualsiasi CA secondario che emette un tipo specifico di certificato coperto da un audit. Gli audit ammissibili includono:

Questi sono gli audit accettati in questo momento per le CA non governative. Ci riserviamo il diritto di modificare gli audit sopra elencati e/o accettare altri audit comparabili in futuro.

Requisiti tecnici

I nuovi certificati radice devono soddisfare i seguenti requisiti tecnici:

  • I certificati radice devono essere certificati x.509 v3.

  • Il nome del soggetto deve contenere un nome significativo della CA (es. Non può essere "Root" o "CA1")

  • Estensione dei vincoli di base: cA = true

  • Utilizzo chiave (se presente): solo keyCertSign e cRLSign

  • I requisiti delle dimensioni delle chiavi di root sono basati su NIST SP 800-57:

         RSA greater or equal to 2048-bit modulus
    
         ECC greater or equal to P256 modulus
    
  • L'algoritmo hash deve essere almeno SHA1. Nessun hash MD2, MD4 o MD5 accettato.

  • Per una dimensione della chiave di root maggiore o uguale a un modulo RSA a 2048 bit, il certificato di root non deve scadere almeno 8 anni dopo l'invio e non oltre il 2030. Una scadenza più lunga può essere offerta a dimensioni di chiave di root più grandi.

  • I certificati CA intermedi sono esclusi dal programma CA principale (vedere Domande frequenti per ulteriori informazioni)

  • La CA non emetterà certificati subordinati o di entità finale MD2, MD4 o MD5 da alcun certificato radice distribuito dal Programma, con effetto dal 15 gennaio 2009.

  • I certificati radice RSA a 1024 bit esistenti ("legacy") possono rimanere in distribuzione dal Programma fino alla scadenza NIST del 31 dicembre 2010, ad eccezione di quanto previsto da Microsoft.

  • La CA può emettere certificati RSA a 1024 bit dai certificati radice distribuiti dal Programma fino alla scadenza NIST del 31 dicembre 2010.

3

Credo che il governo degli Stati Uniti abbia tentato di approvare la legislazione alcuni anni fa, dando loro il diritto di costringere un'autorità di certificazione a generare un certificato valido di una terza parte per le intercettazioni telefoniche e quant'altro. Non sono riuscito a trovare prove di questo, quindi potrei ricordare qualcosa sulla falsariga dei colloqui di DefCon menzionati da Rory.

3
Steve

Supponiamo che un cattivo governo volesse vedere il traffico SSL delle macchine. Quanto è possibile che le CA predefinite siano costrette a emettere un nuovo certificato?

Il predicato e la domanda non sono correlati. Non importa quanto facile o spesso una CA possa essere costretta a emettere un nuovo certificato: il potenziale intercettatore non potrebbe vedere i tuoi dati a meno che non abbiano la chiave privata del certificato che hai già installato. IIRC (ma consiglierei di verificarlo) il CSR non include la chiave privata, quindi la CA non può ottenerla in questo modo. Non possono cambiare le chiavi utilizzate dalle macchine.

Tuttavia è possibile che una CA non autorizzata possa emettere un certificato contraffatto e quindi esiste il potenziale per un attacco MITM sul tuo sito. I recenti problemi con formato MD5 e Etisalat suggeriscono che non è impossibile.

3
symcbean

Cercare di concentrarsi sulla seconda domanda.

Il problema di "Quali certificati root attendibili predefiniti devo rimuovere?" dipende fondamentalmente da chi hai a che fare.

Dovrai "solo" fidarti di tutte le autorità di certificazione che firmano i siti Web a cui ti colleghi.

Per un utente di tipo nonna che visita sempre gli stessi pochi siti, probabilmente una manciata di CA sarà sufficiente, mentre l'elenco non crescerà così rapidamente * per un utente di Internet pesante.

Perché non così rapidamente ? Controintuitivamente, alcune CA sono usate molto (comprese quelle troppo grandi per fallire) mentre altre sono usate a malapena su Internet, come alcune quasi geografiche.

Lo strumento SSLCop da securitybydefault può aiutare a bloccare da paesi di cui non ti fidi/che difficilmente avrai bisogno (es. Non ti aspetti di accedere a un sito web dal governo Brobdingnag, che sembra essere l'utente principale di tale CA): http://www.security-projects.com/?SSLCop

Tuttavia, se non si fida di troppe CA, si finirà per non essere in grado di ottenere un ancoraggio di fiducia ai siti Web di cui gli utenti hanno bisogno (e che accederanno ad essi comunque, nonostante l'avvertimento di sicurezza), che è ugualmente negativo.

1
Ángel

Dimostrazione di creare una CA canaglia utilizzando i punti deboli MD5:

1
Bradley Kreider

Dal 12 giugno 2012 Microsoft ha rilasciato un nuovo programma di aggiornamento che disabiliterà i certificati radice non attendibili e qualsiasi altro certificato segnalato a Microsoft come non affidabile.

L'aggiornamento è disponibile qui e non sono chiaro se questo aggiornamento è già stato distribuito tramite Aggiornamenti di Windows o se si tratta di un aggiornamento fuori banda.

http://support.Microsoft.com/kb/267707

0