理解 HTTPS 的工作原理

目標讀者：理解HTTP協議，對稱和非對稱加密，想要了解HTTPS協議的工作原理。

讀完本文，你能明白

• 什麼是HTTPS，TLS(SSL)，TLS和HTTPS是什麼關係？
• 什麼是證書和數字簽名，它們是如何傳遞信任的？
• HTTPS有什麼樣的功能，它是如何實現這樣的功能的？

簡介

HTTPS，也稱作HTTP over TLS。TLS的前身是SSL，TLS 1.0通常被標示為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。本文著重描述TLS協議的1.2版本。

下圖描述了在TCP/IP協議棧中TLS(各子協議）和HTTP的關係

Credit: Kaushal Kumar Panday From: SSL Handshake and HTTPS Bindings on IIS

其中Handshake protocol，Change Ciper Spec protocol和Alert protocol組成了SSL Handshaking Protocols。

HTTPS和HTTP協議相比提供了

1. 資料完整性：內容傳輸經過完整性校驗
2. 資料隱私性：內容經過對稱加密，每個連線生成一個唯一的加密金鑰
3. 身份認證：第三方無法偽造服務端（客戶端）身份

其中，資料完整性和隱私性由TLS Record Protocol保證，身份認證由TLS Handshaking Protocols實現。

總覽

使用RSA演算法的SSL握手過程是這樣的：

Source: Keyless SSL: The Nitty Gritty Technical Details

1. [明文] 客戶端傳送隨機數client_random和支援的加密方式列表
2. [明文] 伺服器返回隨機數server_random，選擇的加密方式和伺服器證書鏈
3. [RSA] 客戶端驗證伺服器證書，使用證書中的公鑰加密premaster secret傳送給服務端
4. 服務端使用私鑰解密premaster secret
5. 兩端分別通過client_random，server_random和premaster secret生成master secret，用於對稱加密後續通訊內容

證書（Digital certificate）

那麼什麼是證書呢？

證書中包含什麼資訊：

• 證書資訊：過期時間和序列號
• 所有者資訊：姓名等
• 所有者公鑰

為什麼服務端要傳送證書給客戶端？

網際網路有太多的服務需要使用證書來驗證身份，以至於客戶端（作業系統或瀏覽器等）無法內建所有證書，需要通過服務端將證書傳送給客戶端。

客戶端為什麼要驗證接收到的證書？

中間人攻擊

客戶端<------------攻擊者<------------服務端
        偽造證書            攔截請求

客戶端如何驗證接收到的證書？

為了回答這個問題，需要引入數字簽名（Digital Signature）。

+---------------------+
| A digital signature |
|(not to be confused  |
|with a digital       |
|certificate)         |            +---------+              +--------+
| is a mathematical   |----雜湊--->| 訊息摘要  |---私鑰加密--->| 數字簽名 |
|technique used       |            +---------+              +--------+
|to validate the      |
|authenticity and     |
|integrity of a       |
|message, software    |
|or digital document. |
+---------------------+

將一段文字通過雜湊（hash）和私鑰加密處理後生成數字簽名。

假設訊息傳遞在Bob，Susan和Pat三人之間發生。Susan將訊息連同數字簽名一起傳送給Bob，Bob接收到訊息後，可以這樣驗證接收到的訊息就是Susan傳送的

+---------------------+
| A digital signature |
|(not to be confused  |
|with a digital       |
|certificate)         |            +---------+
| is a mathematical   |----雜湊--->|  訊息摘要 |
|technique used       |            +---------+
|to validate the      |                 |
|authenticity and     |                 |
|integrity of a       |                 |
|message, software    |                 對
|or digital document. |                 比
+---------------------+                 |
                                        |
                                        |
          +--------+               +---------+ 
          | 數字簽名 |---公鑰解密--->|  訊息摘要 | 
          +--------+               +---------+

當然，這個前提是Bob知道Susan的公鑰。更重要的是，和訊息本身一樣，公鑰不能在不安全的網路中直接傳送給Bob。

此時就引入了證書頒發機構（Certificate Authority，CA），CA數量並不多，Bob客戶端內建了所有受信任CA的證書。CA對Susan的公鑰（和其他資訊）數字簽名後生成證書。

Susan將證書傳送給Bob後，Bob通過CA證書的公鑰驗證證書籤名。

Bob信任CA，CA信任Susan 使得 Bob信任Susan，信任鏈（Chain Of Trust）就是這樣形成的。

事實上，Bob客戶端內建的是CA的根證書（Root Certificate），HTTPS協議中伺服器會傳送證書鏈（Certificate Chain）給客戶端。

TLS協議

TLS協議包括TLS Record Protocol和TLS Handshake Protocol。總覽中的流程圖僅涉及到TLS Handshake Protocol。

TLS Record Protocol

在TLS協議中，有四種子協議執行於Record protocol之上

• Handshake protocol
• Alert protocol
• Change cipher spec protocol
• Application data protocol

Record protocol起到了這樣的作用

• 在傳送端：將資料（Record）分段，壓縮，增加MAC(Message Authentication Code)和加密
• 在接收端：將資料（Record）解密，驗證MAC，解壓並重組

值得一提的是，Record protocol提供了資料完整性和隱私性保證，但Record型別（type）和長度（length）是公開傳輸的

Record Protocol有三個連線狀態（Connection State），連線狀態定義了壓縮，加密和MAC演算法。所有的Record都是被當前狀態（Current State）確定的演算法處理的。

TLS Handshake Protocol和Change Ciper Spec Protocol會導致Record Protocol狀態切換。

empty state -------------------> pending state ------------------> current state
             Handshake Protocol                Change Cipher Spec

初始當前狀態（Current State）沒有指定加密，壓縮和MAC演算法，因而在完成TLS Handshaking Protocols一系列動作之前，客戶端和服務端的資料都是明文傳輸的；當TLS完成握手過程後，客戶端和服務端確定了加密，壓縮和MAC演算法及其引數，資料（Record）會通過指定演算法處理。

其中，Record首先被加密，然後新增MAC（message authentication code）以保證資料完整性。

TLS Handshaking Protocols

Handshakeing protocols包括Alert Protocol，Change Ciper Spec Protocol和Handshake protocol。本文不會詳細介紹Alert Protocol和Change Ciper Spec Protocol。

使用RSA演算法的握手過程是這樣的（已在總覽中提到）

Source: Keyless SSL: The Nitty Gritty Technical Details

客戶端和服務端在握手hello訊息中明文交換了client_random和server_random，使用RSA公鑰加密傳輸premaster secret，最後通過演算法，客戶端和服務端分別計算master secret。其中，不直接使用premaster secret的原因是：保證secret的隨機性不受任意一方的影響。

除了使用RSA演算法在公共通道交換金鑰，還可以通過Diffie–Hellman演算法。Diffie–Hellman演算法的原理是這樣的：

By Original schema: A.J. Han Vinck, University of Duisburg-Essen SVG version: Flugaal [Public domain], via Wikimedia Commons

使用Diffie–Hellman演算法交換premaster secret的流程

Source: Keyless SSL: The Nitty Gritty Technical Details

小結

TLS Handshaking Protocols協商了TLS Record Protocol使用的演算法和所需引數，並驗證了服務端身份；TLS Record Protocol在協商後保證應用層資料的完整性和隱私性。

TLS Handshaking Protocol的核心是在公開通道上傳遞premaster secret。

Q&A

為什麼傳輸內容不直接使用非對稱加密？

效能

HTTPS能保證正常連線？

no

There are a number of ways in which a man-in-the-middle attacker can attempt to make two entities drop down to the least secure method they support.

攻擊者甚至可以直接丟棄雙方的資料包。

服務端如何驗證客戶端身份？

通過Client Certificate

This message conveys the client’s certificate chain to the server; the server will use it when verifying the CertificateVerify message (when the client authentication is based on signing) or calculating thepremaster secret (for non-ephemeral Diffie- Hellman). The certificate MUST be appropriate for the negotiated cipher suite’s key exchange algorithm, and any negotiated extensions.

Alert protocol有什麼作用？

Closure Alerts：防止Truncation Attack

In a truncation attack, an attacker inserts into a message a TCP code indicating the message has finished, thus preventing the recipient picking up the rest of the message. To prevent this, SSL from version v3 onward has a closing handshake, so the recipient knows the message has not ended until this has been performed.

Error Alerts：錯誤處理

master secret是如何計算的

  master_secret = PRF(pre_master_secret, "master secret",
                      ClientHello.random + ServerHello.random)
                      [0..47];

加密，壓縮和MAC演算法引數是如何計算的

Handshaking Protocols使得客戶端和服務端交換了三個引數：client_random，server_random和master_secret，通過以下演算法生成演算法所需要的引數

To generate the key material, compute

  key_block = PRF(SecurityParameters.master_secret,
                  "key expansion",
                  SecurityParameters.`server_random ` +
                  SecurityParameters.`client_random`);

until enough output has been generated.  Then, the key_block is
partitioned as follows:

  client_write_MAC_key[SecurityParameters.mac_key_length]
  server_write_MAC_key[SecurityParameters.mac_key_length]
  client_write_key[SecurityParameters.enc_key_length]
  server_write_key[SecurityParameters.enc_key_length]
  client_write_IV[SecurityParameters.fixed_iv_length]
  server_write_IV[SecurityParameters.fixed_iv_length]

The master secret is expanded into a sequence of secure bytes, which is then split to a client write MAC key, a server write MAC key, a client write encryption key, and a server write encryption key

使用Diffie-Hellman演算法的TLS握手細節

Source: https://cipherstuff.wordpress.com/

擴充閱讀

• Keyless
• Let’s Encrypt
• Session resume
• 證書Revoke

參考連結

• TLS1.2規範：The Transport Layer Security (TLS) Protocol Version 1.2
• 證書和數字簽名：What is a Digital Signature?
• TLS Handshake：Keyless SSL: The Nitty Gritty Technical Details