# 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，用於保持和恢復連線 最後附上完整互動圖，摘自網路，大致相同，待後續補充 ![網路摘圖](https://img2020.cnblogs.com/blog/685092/202102/685092-20210218173007427-9283398