Come funziona Keyless SSL?

Keyless SSL consente alle organizzazioni che non possono condividere le proprie chiavi private di passare al cloud mantenendo la crittografia SSL/TLS.

Obiettivi di apprendimento

Dopo aver letto questo articolo sarai in grado di:

  • Spiegare i passaggi in un handshake TLS e la differenza tra una chiave di sessione e una chiave privata
  • Scoprire come Keyless SSL separa la parte dell'handshake TLS utilizzando la chiave privata dal resto dell'handshake
  • Scoprire la differenza tra gli handshake Diffie-Hellman ed RSA
  • Capire cos'è il forward secrecy

Argomenti correlati


Vuoi saperne di più?

Abbonati a theNET, il riepilogo mensile di Cloudflare sulle tematiche più discusse in Internet.

Fai riferimento all'Informativa sulla privacy di Cloudflare per scoprire come raccogliamo ed elaboriamo i tuoi dati personali.

Copia link dell'articolo

Cos'è Keyless SSL?

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 interessa la chiave privata dal server del provider, la chiave privata può rimanere in piena sicurezza in possesso dell'azienda. Invece di utilizzare direttamente la chiave privata, per autenticare il proprio server, il provider cloud inoltra e riceve dati dal server dell'azienda. Questa comunicazione avviene su un canale sicuro e crittografato. Pertanto, viene ancora utilizzata una chiave privata, ma non viene condivisa con nessuno al di fuori dell'azienda.

Supponiamo ad esempio che l'azienda Acme Co. adotti il protocollo TLS. Acme Co. memorizzerà in modo sicuro la propria chiave privata su un server di sua proprietà e su cui detiene il controllo. Se Acme Co. passa al cloud e utilizza un provider di servizi cloud per il web hosting, sarà quel provider a detenere la chiave privata. Tuttavia, se Acme Co. passa al cloud con un fornitore che implementa la funzionalità keyless SSL, la chiave privata può rimanere sul server che Acme Co. possiede e controlla, come nell'implementazione TLS non cloud.

Come funziona Keyless SSL?

La funzionalità keyless SSL si fonda sul fatto che c'è un solo momento in cui la chiave privata viene utilizzata durante l'handshake TLS, ovvero all'inizio di una sessione di comunicazione TLS. Keyless SSL funziona suddividendo geograficamente i passaggi dell'handshake TLS. Un fornitore di servizi cloud che adotta la tecnologia keyless SSL sposta la parte del processo relativa alla chiave privata su un altro server, solitamente uno che il cliente mantiene in locale.

Quando durante l'handshake è necessario ricorrere alla chiave privata per la decrittografia o la crittografia dei dati, il server del provider inoltra i dati necessari al server che custodisce la chiave privata del cliente. La chiave privata decrittografa o firma i dati sul server del cliente, che invia i dati a quello del provider, e l'handshake TLS prosegue normalmente.

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.

Come funziona keyless SSL con un handshake TLS con scambio di chiave RSA?

In un handshake RSA, i passaggi dell'handshake TLS 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 sessione. Entrambi devono giungere allo stesso risultato, e tutte le comunicazioni durante la sessione vengono crittografate con queste nuove chiavi.
Handshake SSL (RSA) senza Keyless SSL

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.

Handshake (RSA) Keyless SSL di Cloudflare

Come funziona il keyless SSL con 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. Il messaggio include anche una firma digitale per l'autenticazione. Questa è l'unica volta che la chiave privata viene utilizzata, e conferma che il server è proprio chi dice di essere.
  3. Il client verifica la firma digitale del server 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.
Handshake SSL (Diffie-Hellman) senza Keyless SSL

La chiave privata viene utilizzata solo nel secondo passaggio, ed è qui che keyless SSL diventa rilevante. A questo punto, il provider 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 utilizzate per generare la firma digitale del server e vengono restituite al fornitore del cloud, che le trasmette al cliente. Il client è in grado di verificare questa firma con la chiave pubblica e l'handshake procede. In questo modo, il fornitore del cloud non ha bisogno di toccare la chiave privata.

Keyless SSL (Diffie Hellman) Cloudflare

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.

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.

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 la segretezza in avanti, la chiave privata viene utilizzata per l'autenticazione durante un processo di handshake iniziale, e non viene utilizzata per altri scopi. L'handshake effimero Diffie-Hellman genera le chiavi di sessione separatamente dalla chiave privata e quindi ha il forward secrecy.

Al contrario, RSA non dispone di segretezza in avanti; con la chiave privata compromessa, un utente malintenzionato potrebbe decifrare le chiavi sessione per le conversazioni passate, dato che può decifrare il segreto premaster e le stringhe casuali client e server sono in chiaro. Combinando questi tre fattori, un aggressore può derivare qualunque chiave di sessione.

In che modo Cloudflare implementa Keyless SSL?

Cloudflare è stato il primo provider di servizi cloud a lanciare il keyless SSL, consentendo alle aziende che devono far fronte a rigide restrizioni di sicurezza, come le banche, di passare al cloud. Cloudflare supporta sia gli handshake RSA che gli handshake Diffie-Hellman, in modo che le aziende possano incorporare la segretezza in avanti e proteggersi dalla possibilità che un utente malintenzionato decrittografi i loro dati dopo aver sottratto la 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.