HTTPS原理解析

HTTPS

一些概念

http

概述

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

特色

- 客戶端&服務器
  - 無鏈接
  - 無狀態

密碼學

• 對稱祕鑰算法

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

• 非對稱祕鑰算法

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

• 散列算法

是一種從任何一種數據中建立小的數字「指紋」的方法。散列函數把消息或數據壓縮成摘要，使得數據量變小，將數據的格式固定下來。該函數將數據打亂混合，從新建立一個叫作散列值的指紋。常見算法有：MD五、SHA-25六、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服務，例如：各大銀行、1230六、硬件設備製造商等。目前國際上比較知名CA機構的根證書（CA的公鑰）是預裝在操做系統或瀏覽器的，以下圖。
 
  現實中，網站的證書驗證多數是經過證書鏈的機制實現的，操做系統預裝的證書也都是證書鏈最上層的根證書，而咱們申請到的證書，也可能是二級證書機構頒發的。

http三次握手

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

二、服務器響應syn+ack

三、客戶端發送ack

流程以下（網絡取圖）：

TLS的屢次握手

仍舊以訪問百度爲例，查看https訪問時，TLS的屢次握手
2.一、客戶端發送 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.二、服務器響應 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請求，用於請求客戶端公鑰證書，適用用高安全性場景下的雙向認證。
三、客戶端請求，這一部分協議差別比較大，在TLS1.3中規定該步驟爲最後一步，無需TLS1.2後續確認響應，可是百度使用的TLS1.2，也沒有後續的確認操做了。

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

4.一、服務器建立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，用於保持和恢復鏈接
   最後附上完整交互圖，摘自網絡，大體相同，待後續補充