Aggiornamento 5 Il problema principale (eh) con il modello CA è che nella pratica generale, qualsiasi CA può emettere certificati per qualsiasi dominio, quindi sei vulnerabile al collegamento più debole. Per quanto riguarda le persone di cui ti puoi fidare, dubito che l'elenco sia molto lungo, poiché 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 utilizzato per ottenere l'accesso ai dati degli utenti privati, sia richiedendolo direttamente alle aziende che gestiscono servizi cloud, tramite intercettazioni telefoniche o sempre più ora tramite la coercizione CA o hack: leggera paranoia: le forze che hanno portato all'hacking di DigiNotar.

Qui fornisco alcune specifiche e concludo con collegamenti ad alcune potenziali correzioni.

Nel 2009, Etisalat (proprietà al 60% del governo degli Emirati Arabi Uniti), ha lanciato un innocuo Patch BlackBerry che inseriva spyware nei dispositivi RIM, consentendo il monitoraggio della posta elettronica, quindi difficilmente può essere considerata 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 parte di un iraniano di nome ComodoHacker, contro Comodo: Rogue SSL certificati ("caso comodogate") - F-Secure Weblog. F-Secure rileva che Mozilla include certificati emessi da CA in Cina, Israele, Bermuda, Sud Africa, Estonia, Romania, Slovacchia, Spagna, Norvegia, Colombia, Francia, Taiwan, Regno Unito, Paesi Bassi, Turchia, USA, Hong Kong, Giappone , Ungheria, Germania e Svizzera.

La Tunisia è un altro paese che gestisce una CA ampiamente attendibile e c'è anche una buona documentazione delle azioni del loro governo per invadere la privacy: The Inside Story of How Facebook Responded to tunisian Hacks - Alexis Madrigal - Tecnologia - L'Atlantico

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

Aggiornamento 3 : un altro attacco riuscito apparentemente anche da parte di ComodoHacker era contro la DigiNotar CA. Il loro sito web è stato compromesso a partire dal 2009, ma questo non è stato notato fino a quando DigiNotar è stato utilizzato anche nel 2011 dagli iraniani per firmare falsi certificati per i siti web di Google, Yahoo !, Mozilla, WordPress e The Tor Project. DigiNotar non ha rivelato di essere a conoscenza dell'intrusione nel suo sito per oltre un mese. Ulteriori informazioni su DigiNotar Hack evidenzia i guasti critici del nostro modello di sicurezza Web SSL | Libertà di armeggiare.

Immagino che la gamma di vulnerabilità di varie CA varia abbastanza ampiamente, così come la loro utilità. Quindi suggerirei di rimettere a fuoco la tua strategia. Quando puoi restringerlo a risorse specifiche che stai cercando di proteggere, elimina tutte le CA tranne quelle necessarie per l'utilizzo di tali risorse. Altrimenti, valuta la possibilità di eliminare le CA che ritieni più vulnerabili a coloro che hanno a cuore le tue risorse, 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ù diffuse e attente.

Aggiornamento 2 : c'è un ottimo post sulla riparazione della nostra pericolosa infrastruttura CA at Freedom to Tinker: Costruire una migliore infrastruttura CA

Parla di queste innovazioni:

• ImperialViolet - DNSSEC e TLS

• Notaio di rete - Prospettive: miglioramento dell'autenticazione host in stile SSH con analisi di rete a più percorsi

• Blog sulla sicurezza online di Google: miglioramento della sicurezza dei certificati SSL

Aggiornamento 4 Uno dei nostri IT I post del blog sulla sicurezza nell'agosto 2011 trattano anche il caso del passaggio a DNSSEC: Uno sguardo basato sul rischio per risolvere il problema dell'autorità di certificazione «Blog sulla sicurezza di Stack Exchange

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

Aggiornamento 7 Ancora un altro set di "certificati emessi in modo errato", tramite l'Indian Controller of Certifying Authorities (India CCA) nel 2014: Blog sulla sicurezza online di Google: mantenimento della sicurezza dei certificati digitali

Vedi anche la domanda su Certificate Transparency, che sembra un approccio utile per scoprire in precedenza certificati non validi e violazioni delle norme.

Come scrisse una volta Matt Blaze, le CA ti proteggono da chiunque non siano disposte a prendere soldi. Questo dovrebbe dirti qualcosa su dove si trovano gli incentivi dell'AC e su alcuni potenziali rischi nell'accordo.

Temo che la risposta breve a questa domanda sia che è impossibile saperlo, per quanto posso vedere. Esiste un gran numero di CA predefinite installate nei browser più comuni ed è difficile valutare la probabilità che siano "affidabili" in termini di rilascio di certificati a enti governativi o ad altre organizzazioni.

Se una CA è diventata nota in quanto inaffidabili, verrebbero probabilmente rimossi dagli elenchi di installazione predefiniti del browser, (per @xce di seguito, Diginotar è un buon esempio qui e anche Digicert)

Oltre all'organizzazione che fornisce i certificati volontariamente, c'è il rischio che possono fornire certificati senza effettuare gli opportuni controlli di sicurezza sul richiedente. Alla Defcon un paio di anni fa ci furono diverse presentazioni su questo tema della possibilità di ottenere certificati senza autorizzazione.

Se questa è una preoccupazione significativa, l'unico modo in cui posso pensare di procedere sarebbe creare una white list 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 generale, poiché probabilmente finiresti per rimuovere le CA che hanno problemi di certificati sui siti che desideri utilizzare.

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

• Diversi anni fa (2006, o forse alla fine del 2005) c'era 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 collegamento storico: l'indirizzo era per il nome completo della banca invece dell'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 di Stuxnet si basava, tra le altre tattiche, su certificati rubati. Questi erano "presi in prestito" da produttori di driver di terze parti e, poiché erano "affidabili", potevano essere utilizzati in modo improprio per piantare il malware.

Poi, naturalmente, ci sono gli scenari software in cui la CA non viene nemmeno chiamata in uso, ad es. con thick client che chiamano servizi Web, che non si preoccupano di convalidare il certificato del server ....

Il punto è che se sei preoccupato per MITM su SSL, il più delle volte, non è il coercizione governativa che dovrebbe preoccuparti. Di solito ci sono modi più semplici e 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 io dovresti avere fiducia nel fatto che tu sappia chi è altro .

Per non parlare del fatto che se rimuovi i certificati root standard dall'archivio attendibile, molti siti su Internet non funzioneranno come previsto.

D'altra parte, se hai a che fare con un server / appliance che non necessita di funzionalità di navigazione generali, ma sta comunicando con un server specifico (o un insieme di server) , rimuovi definitivamente TUTTI i certificati root, tranne una whitelist di quelli di cui hai bisogno.
E se vai con la tua CA interna, ancora meglio ...

Ogni CA pubblica una dichiarazione pratica di certificazione che descrive come proteggere le proprie chiavi e convalidare le richieste di certificati prima di emetterle. Un URL alla posizione di questo documento è solitamente incorporato in ogni certificato emesso dalla CA. Supponendo che la CA in questione segua effettivamente questo documento di policy, dovrebbe darti un'indicazione della lunghezza necessaria per accertare la validità dell'entità che richiede i certificati. Cercare dichiarazioni in modo che proteggano le chiavi di firma della CA utilizzando moduli di protezione hardware o moduli crittografici per proteggere le chiavi di firma, l'autenticazione a più fattori e l'autorizzazione basata sul quorum per firmare i certificati, ecc. Questi metodi di protezione lo 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 root del sistema Mac ne ha 175) è lì per tua comodità, per rendere il sistema HTTPS utilizzabile per te e per tutti sul pianeta che non fanno queste domande. Potresti, ovviamente, cacciare ogni CA da questo elenco a meno che tu non abbia personalmente verificato le loro pratiche. Per un sistema chiuso, in cui controlli tutti gli endpoint e hai un numero limitato di parti fidate, questo è fattibile. Il sistema di controllo della versione di Subversion non include alcun certificato radice attendibile, ma puoi aggiungere il tuo a ogni client. Per il Web in generale, l'unico modo che abbiamo trovato per renderlo utilizzabile è che una parte fidata fuori banda (la società che fornisce il tuo sistema operativo o browser, qualunque cosa tu possa pensare di loro) fornisca un elenco di certificati che ti consentono di connetterti a praticamente qualsiasi server abilitato SSL nel mondo.

Hai davvero bisogno di tutti quei certificati nel tuo elenco 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 la lunga lista è che hai CA di tutto il piumaggio, 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 visto casi di credenziali di accesso del rivenditore compromesse e persino chiavi di CA compromesse. Alcune CA richiedono un certificato di incorporazione e la promessa del tuo primogenito, altre si limitano a verificare che puoi ricevere la posta elettronica sul dominio per il quale richiedi un certificato. Eppure ogni CA viene trattata esattamente allo stesso modo dal tuo browser.

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

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

Credo che il governo degli Stati Uniti abbia cercato di approvare una legislazione qualche anno fa che gli conferisse il diritto di obbligare una CA a generare un certificato valido di una terza parte per intercettazioni e quant'altro. Non sono riuscito a trovare prove di ciò, quindi potrei ricordare qualcosa sulla falsariga dei discorsi della DefCon menzionati da Rory.

Supponiamo che qualche malgoverno volesse vedere il traffico SSL delle macchine. Quanto è fattibile che le CA predefinite siano costrette a emettere un nuovo certificato?

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

Tuttavia è possibile che una CA non autorizzata possa emettere un certificato contraffatto - e quindi esiste il potenziale per un attacco MITM al vostro sito. Problemi recenti con il formato MD5 e Etisalat suggeriscono che non è impossibile.

Quando cerchi quale certificato rimuovere in un PC Windows, devi prima assicurarti di non rimuovere i certificati richiesti dal sistema. Se tenti di farlo riceverai il seguente messaggio di errore

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

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

Quando valuti la rimozione di tutti i certificati rimanenti, considera che il Microsoft Root Certificate Program richiede che la CA superi uno di questi standard di controllo:

• ETSI 101042
• ETSI 101 456
• WebTrust for CAs
• WebTrust EV Readiness audit
• ISO 21188 (nota che non accettano ISO 27001)

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

Restrizioni

Il programma prevede anche controlli aggiuntivi che si applicano a cosa sia l'utilizzo delle chiavi. L'utilizzo della chiave è 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

• E-mail protetta (SMIME) EKU = 1.3.6.1.5.5.7.3.4

• Code Signing EKU = 1.3.6.1.5.5.7.3.3

• Time stamping EKU = 1.3.6.1.5.5.7.3. 8

• OCSP EKU = 1.3.6.1.5.5.7.3.9

• Crittografia del file system EKU = 1.3.6.1. 4.1.311.10.3.4

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

Usi delle chiavi vietati

I seguenti utilizzi delle chiavi sono vietati dal programma:

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

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

• Subordinazione qualificata Questo EKU è obsoleto ed è ignorato da Windows.

• Ripristino della chiave Scenario CA aziendale.

• Ripristino di file Questo EKU è obsoleto ed è ignorato da Windows Encrypting File System (EFS).

• Tutti i criteri dell'applicazione Non possiamo concedere "tutti gli utilizzi" poiché questo ammette necessariamente EKU solo aziendali e altri EKU inaccettabili.

• Email del servizio directory replica Scenario aziendale

• Agente di richiesta certificato

• Scenario CA aziendale

• Scenario CA aziendale dell'agente di recupero chiavi

• Certificato di crittografia CA

• Scenario CA aziendale

Criteri di accettazione

Inoltre, è necessario soddisfare i seguenti criteri prima di aggiungere una CA generica o governativa alla radice:

1. La CA deve fornire le informazioni richieste di seguito (vedere St ep 1. Contatta Microsoft) e ricevi l'approvazione preliminare per l'adesione al Programma.

2. La CA deve fornire un certificato di prova emesso dal certificato radice della CA per il test scopi. Facoltativamente, una CA può fornire a Microsoft un URL di un server accessibile pubblicamente in cui è possibile verificare i certificati emessi dal proprio certificato radice. (Vedere le domande frequenti per i dettagli)

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

4. I certificati radice devono essere conformi alla sezione Requisiti tecnici di seguito. In particolare, richiediamo una dimensione minima della chiave crittografica di modulo RSA a 2048 bit per qualsiasi root e tutte le CA emittenti. Microsoft non accetterà più certificati radice con modulo RSA a 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, soprattutto se hanno un modulo RSA a 2048 bit.

5. Certificati emessi da un certificato radice deve supportare l'estensione del punto di distribuzione CRL. Il punto di distribuzione CRL deve puntare a una posizione accessibile pubblicamente.

6. La CA deve disporre di una politica di revoca documentata e la CA dovrebbe essere in grado di revocare qualsiasi certificato emesso.

7. La CA 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 utilizzi dei certificati che abilitiamo devono essere controllati periodicamente. Il rapporto di audit deve documentare l'intero ambito della gerarchia PKI, inclusa qualsiasi sub-CA che emette un tipo specifico di certificato coperto da un audit. I controlli idonei includono:

   • WebTrust for Certificate Authorities v1.0 o successiva, completato da un revisore WebTrust for CAs autorizzato,

   • ETSI TS 101 456 v1.2.1 o successiva,

   • ETSI TS 102042 V1.1.1 o successiva o

   • ISO 21188: 2006, "Infrastruttura a chiave pubblica per i servizi finanziari - Pratiche e quadro politico", completato da un revisore WebTrust autorizzato per CAs o un'autorità di audit che opera secondo le leggi e le politiche per i valutatori nella stessa giurisdizione della CA.

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

Requisiti tecnici

I nuovi certificati radice devono soddisfare i seguenti requisiti tecnici:

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

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

• Estensione vincoli di base: cA = true

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

• Root I requisiti delle dimensioni chiave si basano su NIST SP 800-57:

    RSA maggiore o uguale al modulo di 2048 bit ECC maggiore o uguale al modulo P256  

• L'algoritmo hash deve essere almeno SHA1. Nessun hash MD2, MD4 o MD5 accettato.

• Per una dimensione della chiave radice maggiore o uguale a un modulo RSA a 2048 bit, il certificato radice non deve scadere prima di almeno 8 anni dopo l'invio e non oltre il 2030. È possibile concedere una scadenza più lunga a chiavi radice di dimensioni maggiori.

• I certificati CA intermedi sono esclusi dal programma CA radice (per ulteriori informazioni, vedere le domande frequenti informazioni)

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

• I certificati root RSA esistenti ("legacy") a 1024 bit 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.

Dimostrazione della creazione di una CA non autorizzata utilizzando i punti deboli dell'MD5:

• Ricerca originale
• Copertura stampa

Sto cercando di concentrarmi sulla seconda domanda.

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

Dovrai "solo" fidarti di tutte le CA che firmano uno qualsiasi dei siti web a cui ti colleghi.

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

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

Lo strumento SSLCop da securitybydefault può aiutarti a bloccare i paesi di cui diffidi / di cui non hai bisogno (ad es. non ti aspetti di accedere a un sito web dal governo Brobdingnag, che sembra essere quella CA): http://www.security-projects.com/?SSLCop

Tuttavia, se non ti fidi di troppe CA, finirai per non essere in grado di ottenere un'ancora di fiducia per i siti web di cui i tuoi utenti hanno bisogno (e vi accederanno comunque, nonostante l'avviso di sicurezza), il che è altrettanto negativo.

A partire dal 12 giugno 2012, Microsoft ha rilasciato un nuovo programma di aggiornamento che disabiliterà i certificati di origine 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 Windows Update o se si tratta di un aggiornamento fuori banda.

http://support.microsoft.com/kb/2677070