無密鑰 SSL 的工作原理是什麼?

無密鑰 SSL (Keyless SSL)使無法共用其私密金鑰的組織能夠在維持 SSL/TLS 加密的同時遷移到雲端。

學習目標

閱讀本文後,您將能夠:

  • 解釋 TLS 握手中的步驟以及工作階段金鑰和私密金鑰之間的區別
  • 瞭解無密鑰 SSL 如何將使用私密金鑰的 TLS 握手部分與握手的其他部分分開
  • 瞭解 Diffie-Hellman 和 RSA 握手的區別
  • 瞭解什麼是前向保密

複製文章連結

什麼是無密鑰 SSL?

無密鑰 SSL

無密鑰 SSL 是向使用雲供應商進行 SSL 加密的公司提供的服務。通常情況下,雲供應商必須知道公司的私密金鑰,但 Keyless SSL 是避免這樣做的一種方法。出於監管原因,許多組織無法共用其私密金鑰。通過使用無密鑰 SSL,這些公司在保證金鑰安全的同時,仍能使用 TLS 和雲服務。

SSL(更確切的叫法是 TLS),是一種用於在網路上驗證身份和加密通信的協定。SSL/TLS 要求使用所謂的公開金鑰和私密金鑰,如果某家公司使用該協議來保護往返其網站的流量(請參見 HTTPS),私密金鑰通常仍由該公司持有。但是當該公司遷移到雲端並由供應商提供 TLS 加密時,私密金鑰將改為由該供應商持有。

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.

無密鑰 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.

無密鑰 SSL 僅在供應商角度來看是「無密鑰的」:供應商從不看到客戶的私密金鑰,但客戶仍持有並使用私密金鑰。同時,在客戶端仍如常使用公開金鑰。

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. 客戶端向伺服器發送一個明文「hello」消息,其中包括它們想要使用的協定版本、支持的密碼套件列表和一個稱爲「客戶端隨機數」的隨機數資料短字符串。
  2. 服務器用它的 SSL 憑證、首選的密碼套件和一個不同的隨機資料短字符串(稱爲「伺服器隨機數」)回應(明文)。
  3. 客戶端創建另一個隨機數資料集,稱爲「預主密鑰」。客戶端從伺服器的憑證中獲得公開金鑰,用來加密預主密鑰,並將其發送給伺服器;僅持有私密金鑰的伺服器才能解密預主密鑰。
  4. 伺服器解密預主密鑰。注意,這是唯一一次使用私密金鑰!
  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.
SSL 握手(RSA)——沒有使用無密鑰 SSL

無密鑰 SSL 在第 4 步開始發揮作用。使用無密鑰 SSL後,雲供應商不是自行解密預主密鑰,而是通過加密通道將其發送到客戶代管或控制的一個伺服器。客戶的私密金鑰解密預主密鑰,然後將解密的預主密鑰發回雲供應商。雲供應商的伺服器使用它來生成工作階段密鈅,TLS 通信如常繼續。

Cloudflare 無密鑰 SSL 握手(RSA)

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

臨時 Diffie-Hellman(DHE)握手(「臨時」是指同一個密鈅永遠不使用兩次)使用 Diffie-Hellman 演算法來生成工作階段密鈅,這種算法用於在不安全的通道上交換密鈅。在這種 TLS 握手中,私密金鑰認證與工作階段密鑰生成是兩個獨立的過程。

除了使用的演算法以外,DHE 握手和 RSA 握手的主要區別是預主密鑰生成的方式。在 RSA 握手中,預主密鑰由客戶端生成的隨機資料組成;在 DHE 握手中,客戶端和伺服器使用協定的參數來分別計算相同的預主密鑰。

  1. 正如在 RSA 握手中一樣,客戶端發送想要使用的協定版本、支持的密碼套件列表和客戶端隨機數。
  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. 通過使用客戶端的 DH 參數和伺服器的 DH 參數,雙方分別計算預主密鑰。
  5. 然後,雙方將這個預主密鑰與客戶機隨機數和伺服器隨機數組合起來,以獲得工作階段密鑰。
SSL 握手(Diffie-Hellman)——沒有使用無密鑰 SSL

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.

Cloudflare 無密鑰 SSL (Diffie Hellman)

雖然臨時 Diffie-Hellman 握手的時間比 RSA 握手稍長,其具備稱為前向保密的優勢。由於私密金鑰僅用於認證,攻擊者不能用來發現任何給定的工作階段金鑰。

什麼是工作階段金鑰?

工作階段密鑰是在 TLS 握手完成後,通過 TLS 進行安全通信的雙方使用的對稱密鑰。一旦雙方同意了一組工作階段密鑰,就不再需要使用公開金鑰和私密金鑰了。TLS 為每一個工作階段產生不同的工作階段密鑰。

什麼是前向保密?什麼是完美前向保密?

前向保密確保,即使私密金鑰暴露,加密數據仍維持加密狀態。這也被稱為「完美前向加密」。如果每個通信工作階段都使用獨一無二的工作階段密鈅,且工作階段密鈅是另外從私密金鑰生成的,則有可能實現前向加密。如果單一工作階段密鈅泄露,僅這個工作階段能被攻擊者破解;所有其他工作階段將都保持加密

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.

Cloudflare 如何實施無密鑰 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 (as well as TLS 1.3 handshakes), so that companies can incorporate forward secrecy and protect against the possibility of an attacker decrypting their data after stealing their private key.

Cloudflare 伺服器與私密金鑰伺服器之間的所有通信均通過安全的加密通道進行。此外,儘管需要額外訪問私密金鑰伺服器,Cloudflare 發現無密鑰 SSL 對效能的影響可以忽略不計。

有關無密鑰 SSL 工作原理的更多技術細節,請查看這篇部落格文章。要進一步瞭解 Cloudflare 無密鑰 SSL 的更多資訊,歡迎探索我們的無密鑰 SSL 服務