Questo articolo è la parte 3 di tre della mia serie sulla crittografia SSL/TLS. La parte 1 copre le basi dei concetti di crittografia ben noti. La parte 2 fornisce una breve introduzione a OpenSSL e PKI. Questa parte affronta il problema della debolezza della PKI e introduce due contromisure.
In primo luogo, vorrei introdurre il termine parte fiduciaria . Una relying party è un browser web, un client di posta elettronica, un'applicazione di chat, ecc., che sta tentando di convalidare un certificato x.509. La maggior parte delle volte, la relying party ottiene ciò controllando se una CA nei suoi trust anchor ha firmato il certificato.
[ Potrebbe interessarti anche: Come gestire più coppie di chiavi SSH ]
Escursione:proteggi la tua chiave privata
Come forse saprai dalla Parte 1, la chiave privata è quella che devi proteggere. Questo inizia con la creazione, che dovrebbe avvenire su una macchina affidabile.
Ora potresti chiedere:"Cos'è una macchina affidabile?"
Bene, un servizio online gestito da qualcuno che non conosci non è certo affidabile. Non devi mai creare la tua chiave privata utilizzando alcuni servizi web nel tuo browser perché semplicemente non sai se il fornitore di servizi conserva una copia della chiave creata. Per evitare che ciò accada, potresti invece utilizzare una macchina offline.
Conserva la tua chiave privata solo dove ti serve e tienila al sicuro. Una directory su un server FTP anonimo non è certamente un luogo sicuro. Una condivisione di rete a cui hanno accesso solo utenti privilegiati o un gestore di password che consente di archiviare gli allegati è sicuramente un posto migliore per metterlo.
Nel caso in cui tu abbia copiato accidentalmente la tua chiave privata non protetta in una condivisione di rete o in un repository Git pubblico, rilasciala e creane una nuova. Non puoi essere certo che non sia stato compromesso. Anche se lo elimini immediatamente, non puoi essere sicuro che qualche tipo di meccanismo di snapshot non lo abbia già memorizzato.
Debolezze PKI
Che cos'è la PKI e come funziona è stato discusso nella parte 2 di questa serie. Nel caso non lo sapessi, leggi prima quella parte.
In poche parole, l'intera ragione per cui ci occupiamo di questo pasticcio di certificati è che vogliamo aiutare la parte che fa affidamento a garantire che comunichi con il server corretto e non qualche frode. Quindi otteniamo un certificato firmato da un'autorità di certificazione di cui si fida la relying party e siamo tutti contenti, giusto?
Bene, potremmo esserlo se non ci fosse un grave difetto di progettazione in PKI.
Esistono diverse centinaia di CA che hanno la fiducia della nostra relying party su Internet. Alcune di queste CA dispongono anche di CA secondarie in grado di firmare certificati e di avere la fiducia della relying party. E tutte queste CA possono emettere un certificato per qualsiasi nome di dominio valido.
Quindi, in generale, qualsiasi CA potrebbe emettere un certificato per il tuo dominio e tu non lo sapresti nemmeno. Questo certificato potrebbe essere utilizzato per attacchi man-in-the-middle al tuo dominio, perché la relying party riterrebbe attendibile questo certificato poiché è stato firmato da una CA affidabile.
E questa non è una minaccia teorica. Nel marzo 2015, alcuni certificati non autorizzati emessi da CNNIC venivano utilizzati per decrittografare il traffico che passava attraverso il Great firewall. Nel 2012, una società di sicurezza ha ammesso di aver rilasciato almeno un certificato a una società privata che lo utilizzava per spiare i propri dipendenti. E nel 2011, una società di autorità di certificazione ha subito un hack devastante in cui alcuni dei loro certificati di firma sono stati rubati.
Possibili contromisure
I tre esempi sopra mostrano cosa c'è che non va nella PKI al suo interno. Il design è imperfetto. Quindi come risolverlo? Di seguito sono elencate due tecniche che potrebbero aiutare a mitigare il problema.
Autorizzazione dell'autorità di certificazione (CAA)
Dall'abstract del record di risorse DNS Certification Authority Authorization (CAA) in RFC 8659:"Il record di risorse DNS di Certification Authority Authorization (CAA) consente al titolare di un nome di dominio DNS di specificare una o più autorità di certificazione (CA) autorizzate a emettere certificati per tale nome di dominio. I record di risorse CAA consentono a una CA pubblica di implementare controlli aggiuntivi per ridurre il rischio di emissione non intenzionale del certificato."
Beh, non avrei potuto spiegarlo meglio. CAA consente ai titolari di nomi di dominio di specificare quali CA sono autorizzate a emettere certificati per il nostro dominio e le CA stesse ci promettono di rispettare i nostri record CAA. La RFC 8659 definisce le tre proprietà seguenti:
- emissione contiene come valore il dominio della CA, che è autorizzata dal record CAA ad emettere certificati per un determinato dominio.
- issuewild è sostanzialmente lo stesso di issue ma per i certificati jolly. Se non è impostato issuewild, viene invece utilizzato il valore di issue.
- iodef contiene informazioni di contatto da utilizzare in caso di problemi relativi alla politica CAA.
Esaminiamo i seguenti record di esempio:
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:[email protected]" La prima riga dell'esempio sopra indica che solo la CA Let's Encrypt può emettere certificati per qualsiasi host nel dominio example.com. Qualsiasi altra CA NON DEVE emettere certificati per questo dominio. La seconda riga ti dà un indirizzo email che potresti contattare in caso di problemi.
Poiché il DNS è organizzato gerarchicamente, il record CAA di cui sopra si applica a web.example.com nonché a host.web.example.com e host.sub.web.example.com. Diamo un'occhiata a un altro esempio:
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:[email protected]"
sub.web.example.com IN CAA 0 issue "example-pki.org" Qui solo la CA example-pki.org può emettere certificati per, ad esempio, host.sub.web.example.com. Il record nella terza riga sovrascrive la politica da esempio.com. Penso che tu abbia avuto l'idea.
Naturalmente, i record delle risorse CAA non impedirebbero alle CA non conformi di emettere certificati per domini per i quali non dispongono dell'autorizzazione. Ma rischierebbero di essere rimossi dai trust anchor incorporati, il che significherebbe chiudere l'attività nella maggior parte dei casi.
E c'è ancora la possibilità che una CA autorizzata possa emettere erroneamente un certificato a qualcuno che non è autorizzato a usarlo. Scegli qualche CA di tua fiducia e scegli con saggezza.
Come puoi vedere, CAA non offre sicurezza al 100%, ma è facile da implementare e riduce il rischio di emissione errata del certificato.
Trasparenza del certificato (CT)
La trasparenza del certificato è "... un protocollo sperimentale per registrare pubblicamente l'esistenza di certificati Transport Layer Security (TLS) man mano che vengono emessi o osservati, in un modo che consente a chiunque di controllare l'attività dell'autorità di certificazione (CA) e notare l'emissione di sospetti certificati e di controllare i registri dei certificati stessi. L'intento è che alla fine i client si rifiuterebbero di rispettare i certificati che non compaiono in un registro, costringendo di fatto le CA ad aggiungere tutti i certificati emessi ai registri". (Riassunto RFC 6962)
CT offre una forma di contabilità per i certificati TLS e ti consente di esaminare quali certificati CA emessi per i tuoi nomi di dominio. Per fare ciò, puoi utilizzare servizi come Cert Spotter di sslmate, disponibile anche come versione locale. Ero solito eseguire la versione locale sul mio server privato virtuale, ma a causa della crescita dei registri negli ultimi due anni, sembra impossibile eseguire la scansione dei registri dall'inizio alla fine. Il lavoro è durato settimane e non è terminato; è stato interrotto quando ho dovuto riavviare il mio host per completare gli aggiornamenti.
Oggi nessuna CA è obbligata ad aggiungere certificati emessi ai registri CT, ma la crescita dei registri suggerisce che molti di loro aggiungono già i propri certificati. A mio parere, è solo questione di tempo prima che i principali browser inizino a fidarsi solo dei certificati con una voce di registro CT e li rendano obbligatori.
[ Ottieni questo ebook gratuito:Gestione dei cluster Kubernetes per i manichini. ]
Conclusione
Il design originale del PKI è imperfetto e non è più molto affidabile. Con RFC 8659 e RFC 6962, vengono offerti due metodi per riguadagnare fiducia e aiutare i titolari di nomi di dominio a tenere traccia di chi ha emesso i certificati per i loro domini.
Quindi, d'ora in poi, tieni presente di proteggere le tue chiavi private, impostare i record di risorse CAA per i tuoi domini e iniziare a monitorare i registri CT.