In Cloudflare, siamo orgogliosi di offrire a ogni cliente la possibilità di fornire gratuitamente un certificato TLS per la propria applicazione Internet. Oggi siamo responsabili della gestione del ciclo di vita dei certificati per quasi 45 milioni di certificati dall'emissione alla distribuzione fino al rinnovo. Mentre costruiamo la piattaforma più resiliente e robusta, vogliamo che sia "a prova di futuro" e resistente agli eventi che non possiamo prevedere.
Gli eventi che ci portano a riemettere certificati per i nostri clienti, come compromissioni chiave, vulnerabilità e revoche di massa richiedono un'azione immediata. In caso contrario, i clienti possono essere lasciati non protetti o offline. Quando si verifica uno di questi eventi, vogliamo essere pronti a mitigare l'impatto immediatamente. Ma in che modo?
Avendo un certificato di backup pronto per la distribuzione, con una chiave privata diversa ed emesso da un'autorità di certificazione diversa rispetto al certificato primario che serviamo.
Eventi che portano a una nuova emissione del certificato
Cloudflare emette nuovamente i certificati ogni giorno in un processo che è detto appunto rinnovo dei certificati. Poiché i certificati hanno una data di scadenza, quando Cloudflare rileva che un certificato sta per scadere, avviamo un nuovo ordine di rinnovo del certificato. In questo modo, alla scadenza del certificato, abbiamo già un certificato aggiornato distribuito e pronto per l'uso per la terminazione TLS.
Sfortunatamente, non tutti i rinnovi dei certificati vengono avviati entro la data di scadenza. A volte, eventi imprevedibili come compromissioni delle chiavi possono portare al rinnovo dei certificati. Questo perché è necessario emettere una nuova chiave e quindi anche un certificato corrispondente.
Compromissioni delle chiavi
La compromissione di una chiave si verifica quando una persona o un sistema non autorizzato ottiene la chiave privata utilizzata per crittografare e decrittografare le informazioni segrete: il peggior incubo del team di sicurezza. Tali compromissioni possono essere il risultato di una vulnerabilità, come Heartbleed, in cui un bug in un sistema può causare la perdita della chiave privata. Possono anche essere il risultato di azioni dannose, come un dipendente sleale e disonesto che accede a informazioni non autorizzate. In caso di compromissione di una chiave, è fondamentale che (1) vengano emesse immediatamente nuove chiavi private, (2) vengano distribuiti nuovi certificati e (3) vengano revocati i vecchi certificati.
La vulnerabilità Heartbleed
Nel 2014 è stata individuata la vulnerabilità Heartbleed, che consentiva agli autori di attacchi di estrarre la chiave privata del certificato TLS per qualsiasi server che eseguiva la versione interessata di OpenSSL, una popolare libreria di crittografia. Abbiamo applicato una patch al bug e poi, per precauzione, abbiamo riemesso rapidamente chiavi private e certificati TLS appartenenti a tutti i nostri clienti, anche se nessuna delle nostre chiavi era trapelata. La capacità di Cloudflare di agire rapidamente ha protetto i dati dei nostri clienti dall'esposizione.
Heartbleed è stato un campanello d'allarme. A quel tempo, la scala di Cloudflare era di una magnitudine inferiore. Una vulnerabilità simile su scala odierna richiederebbe settimane, non ore, per emettere nuovamente i certificati di tutti i nostri clienti.
Ora, con i certificati di backup, non dobbiamo preoccuparci di avviare una riemissione di massa in un breve lasso di tempo. Al contrario, i clienti avranno già un certificato che saremo in grado di distribuire istantaneamente. Non solo, il certificato di backup verrà anche avvolto con una chiave diversa rispetto al certificato primario, impedendo che venga influenzato da una compromissione della chiave.
Le compromissioni delle chiavi sono uno dei motivi principali per cui i certificati devono essere riemessi su larga scala ma anche altri eventi possono richiedere la riemissione, comprese le revoche di massa da parte delle autorità di certificazione.
Revoche di massa dalle CA
Oggi il Certificate Authority/Browser Forum (CA/B Forum) è l'organo governativo che stabilisce le regole e gli standard per i certificati. Uno dei requisiti di base stabiliti dal CA/B Forum afferma che le autorità di certificazione sono tenute a revocare i certificati le cui chiavi rischiano di essere compromesse entro 24 ore. Per problemi meno immediati, come l'uso improprio del certificato o la violazione della politica di certificazione di una CA, i certificati devono essere revocati entro cinque giorni. In entrambi i casi, i certificati saranno revocati dalla CA in breve tempo e ne sarà richiesta la riemissione immediata.
Sebbene le revoche di massa non siano comunemente avviate dalle CA, negli ultimi anni si sono verificati alcuni casi. Recentemente, Let’s Encrypt ha dovuto revocare circa 2,7 milioni di certificati quando hanno riscontrato una non conformità nell'implementazione di un problema legato alla convalida del controllo del dominio. In questo caso, i clienti Cloudflare non sono stati interessati.
In un altro caso, una delle autorità di certificazione che utilizziamo ha scoperto che stavano rinnovando certificati in base a token di convalida che non erano conformi agli standard di CA/B Forum. Ciò ha indotto una revoca di massa, con un impatto su circa cinquemila domini gestiti da Cloudflare. Abbiamo collaborato con i nostri clienti e la CA per emettere nuovi certificati prima della revoca, con un impatto minimo.
Sappiamo che gli errori accadono e siamo stati abbastanza fortunati che quando questi problemi sono emersi, i nostri team di ingegneri sono stati in grado di mitigare rapidamente il tutto in modo che nessun cliente venisse colpito. Ma non è sufficiente: i nostri sistemi devono essere a prova di futuro e dobbiamo essere certi che una revoca di 45 milioni di certificati non abbia alcun impatto sui nostri clienti. Con i certificati di backup, saremo pronti per una riemissione di massa, indipendentemente dalla portata.
Per essere resilienti alle revoche di massa avviate dalle nostre CA, emetteremo ogni certificato di backup da una CA diversa dal certificato primario. Ciò aggiungerà un livello di protezione se una delle nostre CA dovrà invocare una revoca di massa, operazione che, una volta avviata, è una bomba a orologeria.
Problemi legati al rinnovo dei certificati
Scala: con un grande potere si ha una grande responsabilità
Quando la vulnerabilità Heartbleed è stata scoperta, abbiamo dovuto emettere nuovamente circa 100.000 certificati. In quel momento, non è stato un vero problema per Cloudflare. Oggi siamo invece responsabili di dieci milioni di certificati. Anche se i nostri sistemi sono in grado di gestire questa scala, ci affidiamo comunque ai nostri partner di autorità di certificazione. In caso di emergenza, non vogliamo affidarci a sistemi che non siamo in grado di controllare. Ecco perché è importante per noi emettere i certificati in anticipo, in modo che durante un disastro, tutto ciò di cui dobbiamo preoccuparci è la distribuzione dei certificati di backup.
Intervento manuale per il completamento della convalida del controllo del dominio
Un altro problema che deriva dalla riemissione dei certificati è la convalida del controllo del dominio (DCV). Questa convalida è un controllo utilizzato per convalidare la proprietà di un dominio prima che un'autorità di certificazione possa emettere un certificato per esso. Quando i clienti di registrano con Cloudflare, possono delegare Cloudflare come loro provider DNS oppure possono decidere di utilizzare Cloudflare come proxy mantenendo il loro attuale provider DNS.
Se Cloudflare funge da provider DNS per un dominio, possiamo aggiungere record di convalida di controllo del dominio (Domain Control Validation, DCV) per conto del nostro cliente. Ciò semplifica notevolmente il processo di emissione e rinnovo del certificato.
I domini che non utilizzano Cloudflare come loro provider DNS, detti zone parziali, devono fare affidamento su altri metodi per completare la convalida. Quando quei domini inviano il loro traffico tramite proxy, possiamo completare la convalida HTTP per loro conto, servendo il token di convalida HTTP dal nostro perimetro. Tuttavia, i clienti che desiderano che il loro certificato sia emesso prima del proxy del loro traffico devono completare manualmente la convalida. Nel caso in cui Cloudflare debba riemettere migliaia o milioni di certificati, ma non possa completare la convalida di controllo del dominio per conto del cliente, sarà necessario un intervento manuale. Sebbene il completamento della DCV non sia un compito arduo, non possiamo fare affidamento sui nostri clienti in caso di emergenza, quando si ha un breve lasso di tempo, con rischi elevati.
È qui che entrano in gioco i certificati di backup. D'ora in poi, ogni emissione di certificato attiverà due ordini: uno per un certificato dalla CA primaria e uno per il certificato di backup. Quando saremo in grado di completare la DCV per conto del cliente, lo faremo per entrambe le CA.
Oggi emettiamo certificati di backup solo per i domini che utilizzano Cloudflare come provider DNS autorevole. In futuro, ordineremo certificati di backup per zone parziali. Ciò significa che per i certificati di backup per i quali non siamo in grado di completare la DCV, forniremo ai clienti i record DCV corrispondenti per ottenere l'emissione del certificato.
Piano di distribuzione dei certificati di backup
Siamo lieti di annunciare che Cloudflare ha iniziato la distribuzione dei certificati di backup su ordini di Universal Certificate per i clienti con piano Free che utilizzano Cloudflare come provider DNS autorevole. Abbiamo lentamente aumentato il numero di ordini di certificati di backup e nelle prossime settimane ci aspettiamo che ogni nuovo ordine di pacchetti di certificati universali avviato su un account Free, Pro o Biz includa un certificato di backup, avvolto con una chiave diversa ed emesso da una CA diversa dal certificato primario.
A fine aprile inizieremo ad emettere certificati di backup per i nostri clienti Enterprise. Se sei un cliente Enterprise e hai domande sui certificati di backup, contatta il tuo account team.
Successivo: certificati di backup per tutti
Oggi, i certificati universali costituiscono il 72% del certificati nella nostra struttura. Ma vogliamo una copertura completa, ecco perché il nostro team continuerà a creare la nostra struttura di certificati di backup per supportare i certificati avanzati e SSL per i certificati SaaS. In futuro, emetteremo anche certificati di backup per i certificati che i nostri clienti caricano da soli, in modo che possano avere un backup su cui poter fare affidamento.
Inoltre, continueremo a migliorare la nostra struttura per rendere istantanea la distribuzione dei certificati di backup, lasciando i nostri clienti al sicuro e online in caso di emergenza.In Cloudflare, la nostra missione è aiutare a costruire un Internet migliore. Con i certificati di backup, aiutiamo a creare un Internet sicuro e affidabile, pronto per qualsiasi disastro. Sei interessato ad aiutarci? Cerchiamo personale.