Come funziona Keyless SSL?

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.

By moving the part of the handshake involving the private key off of the vendor's server, the private key can remain securely in the company's possession. Instead of using the private key directly to authenticate the vendor's server, the cloud vendor forwards data to and receives data from the company's server to accomplish this. This communication occurs over a secure, encrypted channel. Thus, a private key is still used, but it is not shared with anyone outside the company.

For instance, suppose that Acme Co. implements TLS. Acme Co. will securely store their private key on a server that they own and control. If Acme Co. moves to the cloud and uses a cloud service provider for web hosting, that vendor will then have the private key. However, if Acme Co. moves to the cloud with a vendor that implements keyless SSL/TLS instead, the private key can stay on the server that Acme Co. owns and controls, as in the non-cloud TLS implementation.

Come funziona Keyless SSL?

Keyless SSL is based on the fact that there is only one time when the private key is used during the TLS handshake, which occurs at the beginning of a TLS communication session. Keyless SSL works by splitting the steps of the TLS handshake up geographically. A cloud vendor offering keyless SSL moves the private key part of the process to another server, usually a server that the customer keeps on premises.

When the private key becomes necessary during the handshake for decrypting or signing data, the vendor's server forwards the necessary data to the customer's private key server. The private key decrypts or signs the data on the customer's server, the customer's server sends the data back to the vendor's server, and the TLS handshake continues like usual.

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.

How does keyless SSL work with an RSA key exchange TLS handshake?

In an RSA handshake, the steps in a TLS handshake are as follows:

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. Now both client and server have the client random, the server random, and the premaster secret. Independently of each other, they combine these three inputs to come up with session keys. They should both arrive at the same result, and all subsequent communications during the session are encrypted with these new session keys.

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.

How does keyless SSL work with the Ephemeral Diffie-Hellman Key Exchange?

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. The server responds with its chosen cipher suite, a server random, and its SSL certificate. Here the DHE handshake starts to differ from an RSA handshake: The server also sends its Diffie-Hellman (DH) parameter, which will be used for calculating the premaster secret. It also includes a digital signature for authentication. This is the only time the private key is used, and it authenticates that the server is who it says it is.
3. The client verifies the server's digital signature and authenticates the SSL certificate. The client then replies with its DH parameter.
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.

The private key is only used in step 2, and this is where keyless SSL becomes relevant. At this point, the SSL/TLS vendor sends the client random, server random, and server's DH parameter to the customer-controlled server that has the private key. This information is used to generate the server's digital signature and is sent back to the cloud vendor, who passes it on to the client. The client is able to verify this signature with the public key, and the handshake proceeds. This way, the cloud vendor does not need to touch the private key.

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 a protocol set up for forward secrecy, the private key is used for authentication during an initial handshake process, and otherwise it is not used. The ephemeral Diffie-Hellman handshake generates session keys separately from the private key and therefore has forward secrecy.

In contrast, RSA does not have forward secrecy; with the private key compromised, an attacker could determine session keys for past conversations, because they can decrypt the premaster secret and the client randoms and server randoms are in plaintext. By combining these three, the attacker can derive any given session key.

In che modo Cloudflare implementa Keyless SSL?

Cloudflare was the first cloud vendor to release keyless SSL, allowing enterprises facing tight security restrictions, such as banks, to move to the cloud. Cloudflare supports both RSA and Diffie-Hellman handshakes, so that companies can incorporate forward secrecy and protect against the possibility of an attacker decrypting their data after stealing their private key.

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.