TLS 握手中發生什麼事情?| SSL 握手

在 TLS/SSL 握手中,客戶端和伺服器交換 SSL 憑證,並隨機生成資料來創建工作階段金鑰。

學習目標

閱讀本文後,您將能夠:

  • 瞭解什麼是 TLS 握手
  • 瞭解 TLS 握手的作用
  • 說明 TLS 握手中的步驟
  • 探索不同類型的 TLS 握手

相關內容


想要繼續瞭解嗎?

註冊即可收到 Cloudflare 的網路安全學習文章。

請參閱 Cloudflare 的隱私權政策,了解我們如何收集和處理您的個人資料。

複製文章連結

什麽是 TLS 握手?

TLS 握手

TLS is an encryption and authentication protocol designed to secure Internet communications. A TLS handshake is the process that kicks off a communication session that uses TLS. During a TLS handshake, the two communicating sides exchange messages to acknowledge each other, verify each other, establish the cryptographic algorithms they will use, and agree on session keys. TLS handshakes are a foundational part of how HTTPS works.

TLS 與 SSL 握手

SSL, or Secure Sockets Layer, was the original security protocol developed for HTTP. SSL was replaced by TLS, or Transport Layer Security, some time ago. SSL handshakes are now called TLS handshakes, although the "SSL" name is still in wide use.

TLS 握手什麼時候發生?

A TLS handshake takes place whenever a user navigates to a website over HTTPS and the browser first begins to query the website's origin server. A TLS handshake also happens whenever any other communications use HTTPS, including API calls and DNS over HTTPS queries.

通過 TCP 握手打開 TCP 連接後,將發生 TLS 握手。

TLS 握手過程中發生什麼事情?

TLS 握手過程中,客戶端和伺服器將進行如下操作:

  • 指定它们将使用的 TLS 版本(TLS 1.0、1.2、1.3等)
  • 决定它们将使用的密码套件(如下)
  • 通過伺服器的公開密鑰和 SSL 憑證頒發機構的電子簽名驗證伺服器的身份
  • 生成工作階段金鑰,以便在握手完成後使用對稱加密

TLS 握手的步驟是什麼?

TLS 握手是客戶端和伺服器之間交換的一系列資料包(消息)。TLS 握手涉及多個步驟,客戶端和伺服器交換完成握手和進行進一步對話所需的資訊。

The exact steps within a TLS handshake will vary depending upon the kind of key exchange algorithm used and the cipher suites supported by both sides. The RSA key exchange algorithm, while now considered not secure, was used in versions of TLS before 1.3. It goes roughly as follows:

  1. 「用戶端問候(client hello)」消息: 用戶端通過向伺服器發送「問候」消息來開始握手。該消息將包含用戶端支援的 TLS 版本,支援的密碼套件,以及稱為一串稱為「用戶端亂數(client random)」的隨機位元組。
  2. 「伺服器問候(server hello)」消息: 作為對 client hello 消息的回復,伺服器發送一條消息,內含伺服器的 SSL 憑證、伺服器選擇的密碼套件,以及「伺服器亂數(server random)」,即由伺服器生成的另一串隨機位元組。
  3. 身份驗證: 用戶端使用頒發該憑證的憑證授權驗證伺服器的 SSL 憑證。此舉確認伺服器是其聲稱的身份,且客戶端正在與該域的實際所有者進行交互。
  4. 預主密鑰: 用戶端再發送一串隨機位元組,即「預主密鑰(premaster secret)」。預主密鑰是使用公開金鑰加密的,只能使用伺服器的私密金鑰解密。(用戶端從伺服器的 SSL 憑證中獲得公開金鑰。)
  5. 私密金鑰被使用:伺服器對預主密鑰進行解密。
  6. 生成工作階段金鑰:用戶端和伺服器均使用用戶端亂數、伺服器亂數和預主密鑰生成工作階段金鑰。雙方應得到相同的結果。
  7. 用戶端就緒:用戶端發送一條「已完成」消息,該消息用工作階段金鑰加密。
  8. 伺服器就緒:伺服器發送一條「已完成」消息,該消息用工作階段金鑰加密。
  9. 實現安全對稱加密:已完成握手,並使用工作階段金鑰繼續進行通信。

All TLS handshakes make use of asymmetric cryptography (the public and private key), but not all will use the private key in the process of generating session keys. For instance, an ephemeral Diffie-Hellman handshake proceeds as follows:

  1. 用戶端問候:用戶端發送用戶端問候消息,內含協定版本、用戶端亂數和密碼套件清單。
  2. 伺服器問候:伺服器以其 SSL 憑證、其選定的密碼套件和伺服器亂數回復。與上述 RSA 握手不同,伺服器在此消息中還包括以下內容(步驟 3):
  3. Server's digital signature: The server computes a digital signature of all the messages up to this point.
  4. Digital signature confirmed: The client verifies the server's digital signature, confirming that the server is who it says it is.
  5. Client DH parameter: The client sends its DH parameter to the server.
  6. 用戶端和伺服器計算預主密鑰:用戶端和伺服器使用交換的 DH 參數分別計算匹配的預主密鑰,而不像 RSA 握手那樣由用戶端生成預主密鑰並將其發送到伺服器。
  7. 創建工作階段金鑰:與 RSA 握手中一樣,用戶端和伺服器現在從預主密鑰、用戶端亂數和伺服器亂數計算工作階段金鑰。
  8. 客戶端就緒:與 RSA 握手相同。
  9. 伺服器就緒
  10. 實現安全對稱加密

*DH 參數:DH 代表 Diffie-Hellman。Diffie-Hellman 演算法使用指數計算來得到相同的預主密鑰。服務器和客戶端各爲計算提供一個參數,當它們組合在一起時,會在每一邊產生不同的計算,結果是相等的。

要詳細瞭解臨時 Diffie-Hellman 握手與其他類型握手之間的區別,以及它們如何實現前向保密,請參閱什麼是 Keyless SSL?

What is different about a handshake in TLS 1.3?

TLS 1.3 does not support RSA, nor other cipher suites and parameters that are vulnerable to attack. It also shortens the TLS handshake, making a TLS 1.3 handshake both faster and more secure.

The basic steps of a TLS 1.3 handshake are:

  • Client hello: The client sends a client hello message with the protocol version, the client random, and a list of cipher suites. Because support for insecure cipher suites has been removed from TLS 1.3, the number of possible cipher suites is vastly reduced. The client hello also includes the parameters that will be used for calculating the premaster secret. Essentially, the client is assuming that it knows the server’s preferred key exchange method (which, due to the simplified list of cipher suites, it probably does). This cuts down the overall length of the handshake — one of the important differences between TLS 1.3 handshakes and TLS 1.0, 1.1, and 1.2 handshakes.
  • Server generates master secret: At this point, the server has received the client random and the client's parameters and cipher suites. It already has the server random, since it can generate that on its own. Therefore, the server can create the master secret.
  • Server hello and "Finished": The server hello includes the server’s certificate, digital signature, server random, and chosen cipher suite. Because it already has the master secret, it also sends a "Finished" message.
  • Final steps and client "Finished": Client verifies signature and certificate, generates master secret, and sends "Finished" message.
  • 實現安全對稱加密

0-RTT mode for session resumption

TLS 1.3 also supports an even faster version of the TLS handshake that does not require any round trips, or back-and-forth communication between client and server, at all. If the client and the server have connected to each other before (as in, if the user has visited the website before), they can each derive another shared secret from the first session, called the "resumption main secret." The server also sends the client something called a session ticket during this first session. The client can use this shared secret to send encrypted data to the server on its first message of the next session, along with that session ticket. And TLS resumes between client and server.

什麽是密碼套件?

A cipher suite is a set of algorithms for use in establishing a secure communications connection. There are a number of cipher suites in wide use, and an essential part of the TLS handshake is agreeing upon which cipher suite will be used for that handshake.

要進一步瞭解 TLS/SSL,請參閱 SSL 的工作原理。要測試某個網站是否正確使用了 TLS,請訪問 Cloudflare Diagnostic Center