HTTPS原理解析

• 2021 年 2 月 18 日
• 筆記
• HTTPS, Tls, 雜談

HTTPS

一些概念

http

概述

HTTP是一個客戶端（用戶）和服務端（網站）之間請求和應答的標準，通常使用TCP協議。其本身位於TCP/IP協議族的應用層。

特點

  - 客戶端&伺服器
  - 無連接
  - 無狀態

密碼學

• 對稱秘鑰演算法

加密和解密時使用相同的密鑰，或是使用兩個可以簡單地相互推算的密鑰，常見演算法有：AES、DES、SM4。

• 非對稱秘鑰演算法

需要兩個密鑰，一個是公開密鑰，另一個是私有密鑰；公鑰用於加密，私鑰則用作解密。使用公鑰把明文加密後所得的密文，只能用相對應的私鑰才能解密並得到原本的明文。公鑰可以公開，可任意向外發布；私鑰不可以公開。基於公開密鑰加密的特性，它還能提供數字簽名的功能，使電子文件可以得到如同在紙本文件上親筆簽署的效果。常見非對稱演算法有：RSA、DSA、SM2。

• 散列演算法

是一種從任何一種數據中創建小的數字「指紋」的方法。散列函數把消息或數據壓縮成摘要，使得數據量變小，將數據的格式固定下來。該函數將數據打亂混合，重新創建一個叫做散列值的指紋。常見演算法有：MD5、SHA-256、SM3

SSL&TLS

百科給出的解釋是：傳輸層安全性協議（Transport Layer Security）及其前身安全套接層（Secure Sockets Layer）是一種安全協議，目的是為互聯網通訊提供安全及數據完整性保障。網景公司在1994年推出HTTPS協議，以SSL進行加密，這是SSL的起源。IETF將SSL進行標準化後即TLS。目前SSL/TLS已成為互聯網上保密通訊的工業標準。

https

HTTP over SSL/TLS，HTTPS經由HTTP進行通訊，但利用SSL/TLS來加密數據包。HTTPS開發的主要目的，是提供對網站伺服器的身份認證，保護交換資料的隱私與完整性。

HTTPS機制

證書製作的過程

一個網站如果要使用https，第一步就是找CA機構申請證書。簡要流程如下

  1. 申請人伺服器server,生成一對非對稱秘鑰server_prikey、server_pubkey
  1. 申請人把一些申請資訊（使用者、有效期等）sever_info和server_pubkey遞交給CA機構
  1. CA機構驗證申請人身份後，對server_info+server_pubkey+ca_info(ca機構添加的一些資訊)進行散列運算，得到server_hash
  1. CA機構使用自己的私鑰ca_prikey 對server_hash進行簽名，得到sign_server_hash
  1. CA機構根據sign_server_hash+server_pubkey+server_info+ca_info構建成證書server_cert，並下發給申請人
  1. 申請人配置證書到伺服器server，一般情況下會開啟443埠對外提供https的能力。

一些特殊的行業，處於多方面的顧慮，可能會搭建自己的CA服務，例如：各大銀行、12306、硬體設備製造商等。目前國際上比較知名CA機構的根證書（CA的公鑰）是預裝在作業系統或瀏覽器的，如下圖。
 
  現實中，網站的證書驗證多數是通過證書鏈的機制實現的，作業系統預裝的證書也都是證書鏈最上層的根證書，而我們申請到的證書，也多是二級證書機構頒發的。

http三次握手

以訪問百度為例，查看三次握手的抓包數據，其中110.242.68.3是百度伺服器地址，10.100.172.90是我本機的區域網地址（客戶端）。
1、客戶端發送syn：

2、伺服器響應syn+ack

3、客戶端發送ack

流程如下（網路取圖）：

TLS的多次握手

仍舊以訪問百度為例，查看https訪問時，TLS的多次握手
2.1、客戶端發送 client hello

        - Content Type: Handshake (22) 
           - 0x16表示內容類型為握手協議
        - Version: TLS 1.0 (0x0301)
           - 使用TLS1.0
        - Random: 777cd47f33acca3e39c74b2aac641fc1b5bc7c64ff5436d944281495d38899a7
           - 隨機數，4位元組時間戳+28位元組隨機數，可以防重放
        - Session ID: d14d21a0d37f4987c087d2fca80c2beca15dd93d3c90c69fe30b1fb4870fa84f
           - sessionId，0-32位元組隨機數
        - Cipher Suites (18 suites)
           - 客戶端支援的密碼套件演算法列表（優先順序順序）
        - Extension
           - 擴展資訊

2.2、伺服器響應 server hello

        - Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
           - 伺服器根據客戶端秘鑰演算法列表協商的秘鑰
              - TLS 通訊協議類型
              - ECDHE 交換秘鑰演算法
              - RSA 身份驗證演算法，一般為證書使用的演算法
              - AES 通訊時的加密演算法
              - HSA256 哈希演算法，計算簽名使用

** 2.3伺服器下發公鑰證書**
        

        - Certificates (3749 bytes)
           - 下發給客戶端的證書，一般情況下如上圖有兩個證書，一個是根認證機構頒發給二級機構的證書，一個是二級認證機構頒發給百度的證書

2.4伺服器下發交換秘鑰參數、協商秘鑰的公鑰（非必須，使用ECDHE交換秘鑰演算法時需下發參數）

        - Named Curve: secp256r1 (0x0017)
           - 指定非對稱秘鑰演算法的橢圓曲線
        - Pubkey: 
           - 公鑰
        - Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
           - 簽名演算法
        - Signature: 
           - 簽名

2.5服務端響應結束，因為有一些不確定響應，需要最後回復一次客戶端響應完畢。

在伺服器響應結束前還有可能還有一次Certificate Request請求，用於請求客戶端公鑰證書，適用用高安全性場景下的雙向認證。
3、客戶端請求，這一部分協議差異比較大，在TLS1.3中規定該步驟為最後一步，無需TLS1.2後續確認響應，但是百度使用的TLS1.2，也沒有後續的確認操作了。

        - EC Diffie-Hellman Client Params
           - 協商秘鑰客戶端參數
        - Change Cipher Spec Message
           - 告知後續使用密文傳輸
        - Handshake Protocol: Encrypted Handshake Message
           - 密文，如果伺服器能順利解密則協商成功

4.1、伺服器創建session ticket

        - Session Ticket: 
           - 服務的生成的session ticket,session ticket包含sessionId和協商的加密參數以便連接重用。

4.2 服務端告知密文傳輸

**

        - Change Cipher Spec Message
           - 告知客戶端以後使用加密通訊

4.3 伺服器發送密文數據

        - Handshake Protocol: Encrypted Handshake Message
           - 使用協商秘鑰加密後的密文數據

至此，tls整個協商過程結束

https總結

1. http syn握手建立tcp連接

2. 客戶端開始tls握手

3. 服務端開始tls握手，並下發證書供客戶端認證伺服器身份

4. 客戶端和服務端通過秘鑰交換演算法交換秘鑰

5. 通過協商秘鑰安全協商出對稱秘鑰key

6. 後續雙方使用key加密傳輸的數據

7. 服務端創建session ticket，用於保持和恢復連接
   最後附上完整交互圖，摘自網路，大致相同，待後續補充