<address id="r9vd9"><address id="r9vd9"><listing id="r9vd9"></listing></address></address>

      歡迎您光臨深圳塔燈網絡科技有限公司!
      電話圖標 余先生:13699882642

      網站百科

      為您解碼網站建設的點點滴滴

      通過抓包分析HTTPS

      發表日期:2018-07 文章編輯:小燈 瀏覽次數:2224

      //第一步,為服務器端和客戶端準備公鑰、私鑰 # 生成服務器端私鑰 openssl genrsa -out server.key 1024 # 生成服務器端公鑰 openssl rsa -in server.key -pubout -out server.pem//第二步,生成 CA 證書 # 生成 CA 私鑰 openssl genrsa -out ca.key 1024 # X.509 Certificate Signing Request (CSR) Management.ca證書簽名請求 #要求填寫一些資料。Common Name是能訪問的域名 openssl req -new -key ca.key -out ca.csr# X.509 Certificate Data Management.生成ca證書 openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt//第三步,生成服務器端證書 # 服務器端需要向 CA 機構申請簽名證書,在申請簽名證書之前依然是創建自己的 CSR 文件 openssl req -new -key server.key -out server.csr # 向自己的 CA 機構申請證書,簽名過程需要 CA 的證書和私鑰參與,最終頒發一個帶有 CA 簽名的證書 openssl x509 -req -CA ca.crt -CAkey ca.key -CAcreateserial -in server.csr -out server.cr 

      之后再配置nginx的ssl即可

      接下來通過WireShark抓包分析https協議的交互過程

      1. 客戶端首先向服務器端發送一個 Client Hello 的 SSL 握手信息。
      image.png

      雖然只有 Client Hello 兩個單詞,但是其消息體里面包含了豐富的信息,我們在 WireShark 上選擇這行記錄,并雙擊,其里面包含了下面的一些主要信息。

      enter image description here

      (1)Handshake Type:Client Hello(握手類型)。

      (2)Random(隨機數)和一個時間戳。

      enter image description here

      (3)客戶端支持的加密協議套裝。

      enter image description here

      告訴 HTTPS 的服務器端,客戶端能支持上面這 26 種加密協議套裝上列出的算法,讓服務器選擇一個加密協議算法套裝。

      (4)訪問的 Web 服務器的信息:

      enter image description here

      (5)客戶端支持的簽名算法:

      enter image description here

      客戶端告訴服務器其支持 9 種簽名算法,讓服務器端自由選擇一個用于后續的加密通信。

      2. HTTPS 服務器馬上給客戶端回復 4 條 SSL 握手信息

      enter image description here

      HTTPS 服務器馬上給客戶端回復了下面這 4 條 SSL 握手信息。

      • Server Hello
      • Certificate
      • Server Key Exchange Server
      • Hello Done

      下面具體來看這 4 條由 HTTPS 服務器端發出的 4 條消息里面到底有什么內容,其會告訴客戶端什么秘密和信息呢?

      (1)Server Hello SSL 握手信息

      enter image description here

      其重點是把客戶端發送給服務器端的隨機數又給發送回去了,而且還生成了服務器端的 Session ID 并發送給客戶端,最后告訴客戶端,服務器端準備選擇TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384作為秘鑰交互的加密協議套裝,該加密協議的套裝名字肯定出現在客戶端發送給服務器的支持的 26 個列表中,不信你可以翻回去對比一下。

      (2)Certificate

      enter image description here

      SSL 服務器證書信息。在這條 HTTPS 服務器給客戶端回復消息 SSL 握手信息里面,其還會把服務器端的 SSL 證書發送給客戶端,從上圖的轉包信息中,我們能清晰地發現服務器端 SSL 證書的相關信息,比如,通用名字為 iis-web-01,組織單元為 it 等。

      需要注意的是,如果是 SSL 的雙向認證,服務器端也可以要求客戶端把 SSL 證書發送給服務器端(對應的 SSL 握手消息名稱為:CertificateRequest),這個時候,客戶端就會把其 SSL 證書發送給服務器端,從而證明其就是服務器端信任的客戶端。

      (3)Server Key Exchange 握手消息

      enter image description here

      HTTPS 服務器出大招了,告訴了客戶端其將會采用的 EC Diffie-Hellman 算法進行 HTTPS 服務器和客戶端的秘鑰交換。具體什么是 EC Diffie-Hellman 算法,大家可以自行查閱資料,這里不再贅述,并提供了 EC Diffie-Hellman 算法使用到的服務器端的參數:

      • 曲線類型:named_curve: secp256r1
      • 公鑰信息
      • 簽名的算法:rsa_pkcs1_sha1
      • 簽名的信息

      (4)Server Hello Done 握手信息

      握手信息列表結束了。

      enter image description here

      3. HTTPS 客戶端馬上給服務器端回復 3 條 SSL 握手信息

      當客戶端收到服務器端的相關公鑰信息,SSL 證書以及摘要算法和摘要信息后,也不是無動于衷,而是積極的響應了下面的 3 條 SSL 握手信息。

      enter image description here
      • Client Key Exchange
      • Change Cipher Spec
      • Encrypted Handshake Message

      那么這三條 SSL 的握手信息將會透露出什么?客戶端到底想告訴服務器端什么?讓我們一一分解。

      (1)Client Key Exchange 握手信息

      enter image description here

      其給服務器端發送了一條用服務器端公鑰加密的信息,其里面就包含了預備主密碼(Pre-Master secret),其是由客戶端隨機生成,之后會被用作生成主密碼的種子。根據預備密碼,服務器和客戶端會計算出相同的主密碼(Master secret),然后根據主密碼生成下面的比特序列(秘鑰素材)。

      • 對稱密碼的秘鑰
      • 消息認證碼的秘鑰
      • 對稱密碼的 CBC 模式中使用的初始化向量(IV)

      需要注意的是,Client 秘鑰交換的方式主要有兩種,一種是通過 RSA 公鑰密碼進行交互,這個時候客戶端會在發送 ClientKeyExchange 消息時,將經過加密的預備主密碼一起發送給服務器。當使用 Diffie-Hellman 交換秘鑰的時候,客戶端會在發送 ClientKeyExchange 消息時,將 Diffie-Hellman 公開值(Pub Key)一起發送給服務器,根據這個值,客戶端和服務器會各自生成預備主密碼,而且更加這個預備主密碼能夠生成相同的對稱主密碼。

      (2)Change Cipher Spec 握手信息

      enter image description here

      告訴服務器端,我要切換密碼了!

      (3)Encrypted Handshake Message 握手信息

      enter image description here

      客戶端發出使用主密碼加密的結束信息,告訴服務器端:“秘鑰交換握手協議到此結束”。

      4. HTTPS 服務端馬上給客戶端回復 2 條 SSL 握手信息

      enter image description here

      這次輪到服務器端發送“Change Cipher Spec”消息了,服務器告訴客戶端:“好,現在我也要切換密碼了”。

      服務器端用預備主密碼(Pre-Master secret)計算出的主秘鑰加密了一條信息,并發送給客戶端:“好的,秘鑰交換握手協議到此結束”。如果通信雙方都能把結束消息解密成功,說明主秘鑰已經交換成功。就可以發送真正的用主密碼加密的應用數據的信息了!

      5. 服務端用對稱秘鑰把加密過的 HTML 網頁內容發送給客戶端

      enter image description here

      服務器端用成功交換了秘鑰把加密過的 HTML 網頁內容發送給客戶端,客戶端用以前收到過的對稱秘鑰進行解密,HTTPS 通信協議圓滿結束。

      上面的步驟只是把我當前環境下抓取到的使用 TL S1.2 協議規范進行了 HTTPS 通信原理和過程的梳理和解釋,在不同的環境下,其通信過程會有一些差異,比如,如果配置了雙向 SSL 認證,其 SSL 服務器端還會要求客戶端把客戶端的證書發送到服務端,從而驗證客戶端是否是可信任的,另外在進行主密碼交換的過程中,也可能采用 RSA 公鑰密碼,而不是 Diffie-Hellman,此時,其 SSL 握手消息會有所不同,但是整體的流程和交互過程思路基本上保持相同。

      上述具體流程如下圖所示


      7042f5c3d9e3437d5b0b30b30f43c802.jpg
      本頁內容由塔燈網絡科技有限公司通過網絡收集編輯所得,所有資料僅供用戶學習參考,本站不擁有所有權,如您認為本網頁中由涉嫌抄襲的內容,請及時與我們聯系,并提供相關證據,工作人員會在5工作日內聯系您,一經查實,本站立刻刪除侵權內容。本文鏈接:http://www.webpost.com.cn/20428.html
      相關開發語言
       八年  行業經驗

      多一份參考,總有益處

      聯系深圳網站公司塔燈網絡,免費獲得網站建設方案及報價

      咨詢相關問題或預約面談,可以通過以下方式與我們聯系

      業務熱線:余經理:13699882642

      Copyright ? 2013-2018 Tadeng NetWork Technology Co., LTD. All Rights Reserved.    

      • QQ咨詢
      • 在線咨詢
      • 官方微信
      • 聯系電話
        座機0755-29185426
        手機13699882642
      • 預約上門
      • 返回頂部
      国产成人精品综合在线观看