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

什麼是無密鑰 SSL？

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

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

透過將涉及私密金鑰的交握部分移出廠商的伺服器，私密金鑰可以安全地保留在公司的手中。雲端廠商不是直接使用私密金鑰來驗證廠商的伺服器，而是將資料轉寄到公司伺服器並從公司伺服器接收資料來完成此操作。此通訊透過安全的加密通道進行。因此，仍然使用私密金鑰，但不會與公司外部的任何人共用。

例如，假設 Acme Co. 實施 TLS。Acme Co. 將在一個自己擁有和控制的伺服器上儲存其私密金鑰。如果 Acme Co. 轉移到雲端，並使用雲端服務提供者來進行 web 代管，那麼該廠商將持有私密金鑰。但是，如果 Acme Co. 透過實作無金鑰 SSL/TLS 的廠商遷移到雲端，私密金鑰可以保留在 Acme Co. 擁有和控制的伺服器上，就像在非雲端 TLS 實作中一樣。

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

無金鑰 SSL 基於這樣一個事實：私密金鑰僅在 TLS 交握期間使用一次，即 TLS 工作階段開始時。無金鑰 SSL 透過在地理上拆分 TLS 交握的步驟來實現。提供無金鑰 SSL 的雲端廠商將這個過程的私密金鑰部分遷移到另一台伺服器上，通常是客戶的內部部署伺服器。

當在解密或簽署資料的交握過程中需要私密金鑰時，廠商的伺服器會將必要的資料轉寄給客戶的私密金鑰伺服器。私密金鑰在客戶的伺服器上解密或簽署資料，客戶的伺服器將資料傳回廠商的伺服器，TLS 交握像往常一樣繼續。

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

無金鑰 SSL 如何與 RSA 金鑰交換 TLS 交握一起使用？

在 RSA 交握中，TLS 交握中的步驟如下：

1. 客戶端向伺服器發送一個明文「hello」消息，其中包括它們想要使用的協定版本、支持的密碼套件列表和一個稱爲「客戶端隨機數」的隨機數資料短字符串。
2. 服務器用它的 SSL 憑證、首選的密碼套件和一個不同的隨機資料短字符串（稱爲「伺服器隨機數」）回應（明文）。
3. 客戶端創建另一個隨機數資料集，稱爲「預主密鑰」。客戶端從伺服器的憑證中獲得公開金鑰，用來加密預主密鑰，並將其發送給伺服器；僅持有私密金鑰的伺服器才能解密預主密鑰。
4. 伺服器解密預主密鑰。注意，這是唯一一次使用私密金鑰！
5. 現在用戶端和伺服器都有用戶端隨機數、伺服器隨機數和預主金鑰。雙方各自獨立地將這三者合併成工作階段金鑰。它們應該得到相同的結果，並且工作階段期間的所有後續通訊都使用這些新工作階段金鑰進行加密。

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

無金鑰 SSL 如何與 Ephemeral Diffie-Hellman 金鑰交換一起使用？

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

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

1. 正如在 RSA 握手中一樣，客戶端發送想要使用的協定版本、支持的密碼套件列表和客戶端隨機數。
2. 伺服器用它選擇的密碼套件、伺服器隨機數和它的 SSL 憑證進行回應。在這裡，DHE 交握開始與 RSA 交握存在差異：伺服器也發送其 Diffie-Hellman (DH) 參數，其將用於計算預主金鑰。它還包括用於驗證的數位簽名。這是唯一一次使用私密金鑰，它驗證伺服器是其聲稱的身份。
3. 用戶端會驗證伺服器的數位簽章並驗證 SSL 憑證。然後，用戶端會以其 DH 參數回覆。
4. 通過使用客戶端的 DH 參數和伺服器的 DH 參數，雙方分別計算預主密鑰。
5. 然後，雙方將這個預主密鑰與客戶機隨機數和伺服器隨機數組合起來，以獲得工作階段密鑰。

私密金鑰僅在第 2 步使用，這是無金鑰 SSL 發揮作用的時候。此時，SSL/TLS 廠商將用戶端隨機數、伺服器隨機數和伺服器的 DH 參數發送到客戶控制的具有私密金鑰的伺服器。此資訊用於產生伺服器的數位簽名並傳回雲端廠商，雲端廠商將其傳遞給用戶端。用戶端能夠使用公開金鑰驗證此簽名，然後交握繼續進行。這樣一來，雲端廠商不需要接觸私密金鑰。

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

什麼是工作階段金鑰？

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

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

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

在設定了前向保密的通訊協定中，私密金鑰用於首次交握過程中的認證，否則不會使用。臨時 Diffie-Hellman 交握從私密金鑰獨立產生工作階段金鑰，因此具備前向保密性。

相比之下，RSA 沒有前向保密性；私密金鑰泄露後，攻擊者可以確定過去對話的工作階段金鑰，因爲他們可以解密預主金鑰，且用戶端隨機數和伺服器隨機數都是純文字形式。透過結合這三者，攻擊者能推導出任何給定工作階段密鈅。

Cloudflare 如何實施無密鑰 SSL？

Cloudflare 是第一個發佈無金鑰 SSL 的雲端廠商，讓面臨嚴格安全限制的企業（例如銀行）能夠遷移到雲端。Cloudflare 同時支援 RSA 和 Diffie-Hellman 交握，因此公司可以採用前向保密並防止攻擊者在竊取其私密金鑰後解密其資料。

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

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