Keyless SSL allows organizations that cannot share their private keys to move to the cloud while maintaining SSL/TLS encryption.
What is keyless SSL?
Keyless SSL is a service for companies that use a cloud vendor for SSL encryption. Usually, this would mean that the cloud vendor has to know the company’s private key, but keyless SSL is a way to circumvent that. For regulatory reasons, many organizations cannot share their private keys. With keyless SSL, these organizations can still use TLS and leverage the cloud while keeping the key secure.
SSL, more accurately known as TLS, is a protocol for authenticating and encrypting communications over a network. SSL/TLS requires the use of what’s called a public key and a private key, and in the case of a company using the protocol to secure traffic to and from its website (see HTTPS), the private key typically remains in the company’s possession. But when a company moves to the cloud and a vendor provides TLS encryption, the vendor has the private key instead.
Moving the part of the handshake involving the private key of the vendor’s server can keep the private key 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. This communication occurs over a secure, encrypted channel. Thus, a private key is still used but 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 they own and control. If Acme Co. moves to the cloud and uses a cloud service provider for web hosting, that vendor will 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 Acme Co. owns and controls, as in the non-cloud TLS implementation.
How does keyless SSL work?
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 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 as usual.
Keyless SSL is only “keyless” from the cloud vendor’s point of view: they never see their customer’s private key, but the customer still has and uses it. Meanwhile, the public key is still used on the client side as usual.
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:
- The client sends the server a plaintext “hello” message that includes the protocol version they want to use, a list of supported cipher suites, and a short string of random data called the “client random.”
- The server responds (in plaintext) with its SSL certificate, preferred cipher suite, and a short string of random data called the “server random.”
- The client creates another random data set called the “premaster secret.” Taking the public key from the server’s SSL certificate, the client encrypts the premaster secret and sends it to the server; only someone with the private key can decrypt it.
- The server decrypts the premaster secret. Note that this is the only time the private key is used!
- 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 arrive at the same result, and all subsequent communications during the session are encrypted with these new session keys.
Keyless SSL comes into play in step 4. With keyless SSL, instead of decrypting the premaster secret, the cloud vendor sends it in encrypted form over a secure channel to a server that the customer hosts or controls. The customer’s private key decrypts the premaster secret, and then the decrypted premaster secret is sent back to the cloud vendor. The cloud vendor’s server uses this to derive the session keys, and TLS communications continue as usual.
How does keyless SSL work with the Ephemeral Diffie-Hellman Key Exchange?
An ephemeral Diffie-Hellman (DHE) handshake (“ephemeral” because the same key is never used twice) generates session keys using the Diffie-Hellman algorithm, a way of exchanging keys over an unsecured channel. With this kind of TLS handshake, private key authentication is a separate process from session key generation.
The main difference between the DHE handshake and an RSA handshake, aside from the algorithms used, is how the premaster secret is generated. In an RSA handshake, the premaster secret comprises randomized data generated by the client; in a DHE handshake, the client and the server use agreed-upon parameters to calculate the same premaster secret separately.
- Like in an RSA handshake, the client sends the protocol version they want to use, a list of supported cipher suites, and the client randomizes.
- The server responds with its chosen cipher suite, a random server, and an 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, which authenticates that the server is who it says it is.
- The client verifies the server’s digital signature and authenticates the SSL certificate. The client then replies with its DH parameter.
- Both parties calculate the premaster secret using the client’s DH parameter and the server’s DH parameter.
- They then combine this premaster secret with the client and server random to get the session keys.
The private key is only used in step 2, where keyless SSL becomes relevant. At this point, the SSL/TLS vendor sends the client, server random, and the server’s DH parameter to the customer-controlled server with the private key. This information generates the server’s digital signature and is sent back to the cloud vendor, who passes it on to the client. The client can verify this signature with the public key, and the handshake proceeds. This way, the cloud vendor does not need to touch the private key.
Although ephemeral Diffie-Hellman handshakes take slightly longer than RSA handshakes, they have the advantage of forward secrecy. Because the private key is only used for authentication, an attacker cannot use it to discover any given session key.
What is a session key?
A session key is a symmetric key used by both sides of a secure communication over TLS, after the TLS handshake is completed. Once the two sides agree upon a set of session keys, there is no need to use the public and private keys anymore. TLS generates different session keys for each unique session.
What is forward secrecy? What is perfect forward secrecy?
Forward secrecy ensures encrypted data stays encrypted even if the private key is exposed. This is also known as “perfect forward secrecy.” Forward secrecy is possible if a unique session key is used for each communication session, and if the session key is generated separately from the private key. If a single session key is compromised, an attacker can decrypt that session; all other sessions will remain encrypted.
In a protocol set up for forward secrecy, the private key is used for authentication during an initial handshake process; otherwise, it is not used. The ephemeral Diffie-Hellman handshake generates session keys separately from the private key, which 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.
