Come funziona Keyless SSL? | Forward secrecy

Cos'è Keyless SSL?

Keyless SSL è un servizio per le aziende che utilizzano un fornitore cloud per la crittografia SSL. Di solito ciò implica che il fornitore del cloud deve conoscere la chiave privata dell'azienda, ma Keyless SSL è un modo per aggirare questo ostacolo. Per motivi normativi, molte organizzazioni non possono condividere le proprie chiavi private. Con Keyless SSL, queste organizzazioni sono ancora in grado di utilizzare TLS e sfruttare il cloud mantenendo la chiave al sicuro.

SSL, meglio noto come TLS, è un protocollo per l'autenticazione e la crittografia delle comunicazioni su una rete. SSL/TLS richiede l'uso di una cosiddetta chiave pubblica e una chiave privata, e nel caso di un'azienda che utilizza il protocollo per proteggere il traffico da e verso il proprio sito Web (vedi HTTPS), la chiave privata in genere rimane in possesso dell'azienda. Ma quando un'azienda passa al cloud e un fornitore fornisce la crittografia TLS, il fornitore ha invece la chiave privata.

Spostando la parte dell'handshake che coinvolge la chiave privata dal server del fornitore, la chiave privata può rimanere in possesso dell'azienda in modo sicuro. Invece di utilizzare direttamente la chiave privata per generare chiavi di sessione, il fornitore del cloud ottiene le chiavi di sessione dall'azienda su un canale sicuro e utilizza tali chiavi per mantenere la crittografia. Pertanto, viene ancora utilizzata una chiave privata, ma non condivisa con nessuno al di fuori dell'azienda.

Ad esempio, supponiamo che Acme Co. implementi SSL. Acme Co. memorizzerà in modo sicuro la propria chiave privata su un server di sua proprietà e che controlla. Se Acme Co. passa al cloud e utilizza un provider di servizi cloud per l'hosting Web, quel fornitore avrà la chiave privata. Tuttavia, se Acme Co. passa al cloud con un fornitore che implementa SSL senza chiave, la chiave privata può rimanere sul server che Acme Co. possiede e controlla, come nell'implementazione SSL non cloud.

Come funziona Keyless SSL?

Keyless SSL si basa sul fatto che esiste una sola volta in cui la chiave privata viene utilizzata durante l'handshake TLS, che si verifica all'inizio di una sessione di comunicazione TLS. Keyless SSL funziona suddividendo i passaggi dell'handshake TLS. Un fornitore di servizi cloud che offre SSL senza chiavi sposta la parte del processo relativa alla chiave privata su un altro server, di solito un server che il cliente mantiene in sede.

Quando la chiave privata diventa necessaria durante l'handshake per la decrittografia o la crittografia dei dati, il server del fornitore inoltra i dati necessari al server della chiave privata del cliente. La chiave privata crittografa o decrittografa i dati sul server del cliente e invia i dati al server del fornitore e l'handshake TLS continua come al solito.

Keyless SSL è "senza chiave" solo dal punto di vista del fornitore del cloud: non vede mai la chiave privata del cliente, ma il cliente la possiede e la utilizza. Nel frattempo, la chiave pubblica viene ancora utilizzata sul lato client come di consueto.

Cos'è una chiave di sessione?

Una chiave di sessione è una chiave simmetrica utilizzata da entrambi i lati di una comunicazione sicura su TLS, dopo il completamento dell'handshake TLS. Una volta che le due parti hanno concordato un set di chiavi di sessione, non è più necessario utilizzare le chiavi pubblica e privata. TLS genera chiavi di sessione diverse per ogni sessione univoca.

Quali sono i passaggi per la generazione delle chiavi di sessione?

Tutto dipende dal tipo di algoritmo di scambio delle chiavi utilizzato nell'handshake TLS. I due principali sono l'algoritmo di scambio di chiavi RSA e l'algoritmo di scambio di chiavi effimero Diffie-Hellman.

Lo scambio delle chiavi RSA

In un handshake RSA, i passaggi in un handshake TLS per la creazione di chiavi di sessione sono i seguenti:

1. Il client invia al server un messaggio "hello" in testo semplice che include la versione del protocollo che desidera utilizzare, un elenco di suite di crittografia supportate e una breve stringa di dati casuali denominata "casuale del client".
2. Il server risponde (in chiaro) con il suo certificato SSL, la sua suite di cifratura preferita e un'altra breve stringa di dati casuali, chiamata "casuale del server".
3. The client creates another random set of data, called the "premaster secret." Prelevando la chiave pubblica dal certificato SSL del server, il client crittografa il segreto del premaster e lo invia al server; solo qualcuno con la chiave privata può decifrare il segreto del premaster.
4. Il server decrittografa il segreto del premaster. Nota che questa è l'unica volta che viene utilizzata la chiave privata!
5. Ora sia il client che il server hanno la stringa casuale client, la stringa casuale server e il segreto premaster. Indipendentemente l'uno dall'altro, combinano questi tre input per ottenere le chiavi di sessione. Dovrebbero arrivare entrambi allo stesso risultato e tutte le comunicazioni successive durante la sessione vengono crittografate con queste nuove chiavi.

Keyless SSL entra in gioco nel passaggio 4. Con Keyless SSL, invece di decifrare il segreto premaster stesso, il fornitore del cloud lo invia in forma crittografata su un canale sicuro a un server che il cliente ospita o controlla. La chiave privata del cliente decrittografa il segreto premaster, quindi il segreto premaster decrittografato viene restituito al fornitore del cloud. Il server del fornitore del cloud lo utilizza per derivare le chiavi di sessione e le comunicazioni TLS continuano normalmente.

Lo scambio di chiavi effimero Diffie-Hellman

Un handshake effimero Diffie-Hellman (DHE) ("effimero" perché la stessa chiave non viene mai utilizzata due volte) genera chiavi di sessione utilizzando l'algoritmo Diffie-Hellman, un modo per scambiare le chiavi su un canale non sicuro. Con questo tipo di handshake TLS, l'autenticazione della chiave privata è un processo separato dalla generazione della chiave di sessione.

La differenza principale tra l'handshake DHE e l'handshake RSA, a parte gli algoritmi utilizzati, è il modo in cui viene generato il segreto del premaster. In un handshake RSA, il segreto premaster è costituito da dati randomizzati generati dal client; in un handshake DHE, il client e il server utilizzano parametri concordati per calcolare separatamente lo stesso segreto premaster.

1. Proprio come in un handshake RSA, il client invia la versione del protocollo che desidera utilizzare, un elenco di suite di crittografia supportate e la stringa casuale client.
2. l server risponde con la suite di cifratura scelta, una stringa casuale server e il suo certificato SSL. Qui l'handshake DHE inizia a differire da un handshake RSA: il server invia anche il suo parametro Diffie-Hellman (DH), che verrà utilizzato per calcolare il segreto premaster. Crittografa anche la stringa casuale client, la stringa casuale server e il parametro DH con la chiave privata del server. Questa è l'unica volta che la chiave privata viene utilizzata e autentica che il server è proprio chi dice di essere.
3. Il client decritta il messaggio del server con la chiave pubblica e autentica il certificato SSL. Il client quindi risponde con il relativo parametro DH.
4. Utilizzando il parametro DH del client e il parametro DH del server, entrambe le parti calcolano il segreto premaster separatamente l'uno dall'altro.
5. Quindi combinano questo segreto premaster con la stringa casuale client e la stringa casuale server per ottenere le chiavi di sessione.

La chiave privata viene utilizzata solo nel passaggio 2, ed è qui che Keyless SSL diventa rilevante. A questo punto, il fornitore SSL/TLS invia la stringa casuale client, la stringa casuale server e il parametro DH del server al server controllato dal cliente che dispone della chiave privata. Queste informazioni vengono crittografate con la chiave privata e vengono restituite in forma crittografata al fornitore del cloud, che le trasmette al cliente. Il client è in grado di decifrare questi dati con la chiave pubblica e l'handshake procede. In questo modo, il fornitore del cloud non ha bisogno di toccare la chiave privata.

Gli handshake effimeri Diffie-Hellman, sebbene richiedano un po' più di tempo degli handshake RSA, hanno il vantaggio di qualcosa chiamato forward secrecy, o segretezza diretta. Poiché la chiave privata viene utilizzata solo per l'autenticazione, un utente malintenzionato non può utilizzarla per scoprire una determinata chiave di sessione.

Che cos'è il forward secrecy? Che cos'è il forward secrecy perfetto?

Il forward secrecy assicura che i dati crittografati rimangano crittografati anche se la chiave privata è esposta. Questo è anche noto come "forward secrecy perfetto". Il forward secrecy è possibile se viene utilizzata una chiave di sessione univoca per ogni sessione di comunicazione e se la chiave di sessione viene generata separatamente dalla chiave privata. Se una singola chiave di sessione viene compromessa, solo quella sessione può essere decifrata da un utente malintenzionato; tutte le altre sessioni rimarranno crittografate.

In un protocollo impostato per il forward secrecy, la chiave privata viene utilizzata per l'autenticazione durante un processo di handshake iniziale, altrimenti non viene utilizzata per la crittografia. L'handshake effimero Diffie-Hellman genera le chiavi di sessione separatamente dalla chiave privata e quindi ha il forward secrecy.

Al contrario, RSA non ha il forward secrecy; con la chiave privata compromessa, un utente malintenzionato potrebbe decifrare le chiavi di sessione per le conversazioni passate, perché può decifrare il segreto premaster e le stringhe casuali client e server sono in chiaro. Combinando questi tre fattori, l'attaccante può derivare una determinata chiave di sessione.

In che modo Cloudflare implementa Keyless SSL?

Cloudflare è stato il primo fornitore di cloud a rilasciare Keyless SSL, consentendo alle aziende che devono far fronte a rigide restrizioni di sicurezza, come le banche, di passare al cloud. Cloudflare supports both RSA and Strette di mano Diffie-Hellman, in modo che le aziende possano incorporare la segretezza in avanti tramite Diffie-Hellman e proteggersi dalla possibilità che un utente malintenzionato decrittografa i loro dati dopo aver rubato la loro chiave privata.

Tutte le comunicazioni tra i server Cloudflare e i server di chiavi private avvengono su un canale sicuro e crittografato. Inoltre, Cloudflare ha scoperto che SSL senza chiave ha un impatto trascurabile sulle prestazioni nonostante i viaggi extra al server della chiave privata.

Per altri dettagli tecnici sulla modalità di funzionamento di Keyless SSL, dai un'occhiata a questo post sul blog. Per ulteriori informazioni su SSL senza chiave di Cloudflare, esplora i dettagli del nostro servizio Keyless SSL.