HTTPS原理解析

聞雞睡覺發表於2021-02-18
HTTP

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的公鑰）是預裝在作業系統或瀏覽器的，如下圖。
image.png image.png
  現實中，網站的證書驗證多數是通過證書鏈的機制實現的，作業系統預裝的證書也都是證書鏈最上層的根證書，而我們申請到的證書，也多是二級證書機構頒發的。

http三次握手

以訪問百度為例，檢視三次握手的抓包資料，其中110.242.68.3是百度伺服器地址，10.100.172.90是我本機的區域網地址（客戶端）。
1、客戶端傳送syn：
image.png
2、伺服器響應syn+ack
image.png
3、客戶端傳送ack
image.png
流程如下（網路取圖）：

TLS的多次握手

仍舊以訪問百度為例，檢視https訪問時，TLS的多次握手
2.1、客戶端傳送 client hello
image.png

        - 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
image.png

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

** 2.3伺服器下發公鑰證書**
image.png        image.png

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

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

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

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

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

4.1、伺服器建立session ticket
image.png

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

4.2 服務端告知密文傳輸
image.png
**

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

4.3 伺服器傳送密文資料
image.png

        - Handshake Protocol: Encrypted Handshake Message
           - 使用協商祕鑰加密後的密文資料

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

https總結

  1. http syn握手建立tcp連線

  2. 客戶端開始tls握手

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

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

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

  6. 後續雙方使用key加密傳輸的資料

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

    網路摘圖

相關文章