發表日期:2018-07 文章編輯:小燈 瀏覽次數:2025
//第一步,為服務器端和客戶端準備公鑰、私鑰 # 生成服務器端私鑰 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
雖然只有 Client Hello 兩個單詞,但是其消息體里面包含了豐富的信息,我們在 WireShark 上選擇這行記錄,并雙擊,其里面包含了下面的一些主要信息。
(1)Handshake Type:Client Hello(握手類型)。
(2)Random(隨機數)和一個時間戳。
(3)客戶端支持的加密協議套裝。
告訴 HTTPS 的服務器端,客戶端能支持上面這 26 種加密協議套裝上列出的算法,讓服務器選擇一個加密協議算法套裝。
(4)訪問的 Web 服務器的信息:
(5)客戶端支持的簽名算法:
客戶端告訴服務器其支持 9 種簽名算法,讓服務器端自由選擇一個用于后續的加密通信。
HTTPS 服務器馬上給客戶端回復了下面這 4 條 SSL 握手信息。
下面具體來看這 4 條由 HTTPS 服務器端發出的 4 條消息里面到底有什么內容,其會告訴客戶端什么秘密和信息呢?
(1)Server Hello SSL 握手信息
其重點是把客戶端發送給服務器端的隨機數又給發送回去了,而且還生成了服務器端的 Session ID 并發送給客戶端,最后告訴客戶端,服務器端準備選擇TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
作為秘鑰交互的加密協議套裝,該加密協議的套裝名字肯定出現在客戶端發送給服務器的支持的 26 個列表中,不信你可以翻回去對比一下。
(2)Certificate
SSL 服務器證書信息。在這條 HTTPS 服務器給客戶端回復消息 SSL 握手信息里面,其還會把服務器端的 SSL 證書發送給客戶端,從上圖的轉包信息中,我們能清晰地發現服務器端 SSL 證書的相關信息,比如,通用名字為 iis-web-01,組織單元為 it 等。
需要注意的是,如果是 SSL 的雙向認證,服務器端也可以要求客戶端把 SSL 證書發送給服務器端(對應的 SSL 握手消息名稱為:CertificateRequest),這個時候,客戶端就會把其 SSL 證書發送給服務器端,從而證明其就是服務器端信任的客戶端。
(3)Server Key Exchange 握手消息
HTTPS 服務器出大招了,告訴了客戶端其將會采用的 EC Diffie-Hellman 算法進行 HTTPS 服務器和客戶端的秘鑰交換。具體什么是 EC Diffie-Hellman 算法,大家可以自行查閱資料,這里不再贅述,并提供了 EC Diffie-Hellman 算法使用到的服務器端的參數:
named_curve: secp256r1
rsa_pkcs1_sha1
(4)Server Hello Done 握手信息
握手信息列表結束了。
當客戶端收到服務器端的相關公鑰信息,SSL 證書以及摘要算法和摘要信息后,也不是無動于衷,而是積極的響應了下面的 3 條 SSL 握手信息。
那么這三條 SSL 的握手信息將會透露出什么?客戶端到底想告訴服務器端什么?讓我們一一分解。
(1)Client Key Exchange 握手信息
其給服務器端發送了一條用服務器端公鑰加密的信息,其里面就包含了預備主密碼(Pre-Master secret),其是由客戶端隨機生成,之后會被用作生成主密碼的種子。根據預備密碼,服務器和客戶端會計算出相同的主密碼(Master secret),然后根據主密碼生成下面的比特序列(秘鑰素材)。
需要注意的是,Client 秘鑰交換的方式主要有兩種,一種是通過 RSA 公鑰密碼進行交互,這個時候客戶端會在發送 ClientKeyExchange 消息時,將經過加密的預備主密碼一起發送給服務器。當使用 Diffie-Hellman 交換秘鑰的時候,客戶端會在發送 ClientKeyExchange 消息時,將 Diffie-Hellman 公開值(Pub Key)一起發送給服務器,根據這個值,客戶端和服務器會各自生成預備主密碼,而且更加這個預備主密碼能夠生成相同的對稱主密碼。
(2)Change Cipher Spec 握手信息
告訴服務器端,我要切換密碼了!
(3)Encrypted Handshake Message 握手信息
客戶端發出使用主密碼加密的結束信息,告訴服務器端:“秘鑰交換握手協議到此結束”。
這次輪到服務器端發送“Change Cipher Spec”消息了,服務器告訴客戶端:“好,現在我也要切換密碼了”。
服務器端用預備主密碼(Pre-Master secret)計算出的主秘鑰加密了一條信息,并發送給客戶端:“好的,秘鑰交換握手協議到此結束”。如果通信雙方都能把結束消息解密成功,說明主秘鑰已經交換成功。就可以發送真正的用主密碼加密的應用數據的信息了!
服務器端用成功交換了秘鑰把加密過的 HTML 網頁內容發送給客戶端,客戶端用以前收到過的對稱秘鑰進行解密,HTTPS 通信協議圓滿結束。
上面的步驟只是把我當前環境下抓取到的使用 TL S1.2 協議規范進行了 HTTPS 通信原理和過程的梳理和解釋,在不同的環境下,其通信過程會有一些差異,比如,如果配置了雙向 SSL 認證,其 SSL 服務器端還會要求客戶端把客戶端的證書發送到服務端,從而驗證客戶端是否是可信任的,另外在進行主密碼交換的過程中,也可能采用 RSA 公鑰密碼,而不是 Diffie-Hellman,此時,其 SSL 握手消息會有所不同,但是整體的流程和交互過程思路基本上保持相同。
上述具體流程如下圖所示
日期:2018-04 瀏覽次數:6763
日期:2017-02 瀏覽次數:3438
日期:2017-09 瀏覽次數:3659
日期:2017-12 瀏覽次數:3529
日期:2018-12 瀏覽次數:4819
日期:2016-12 瀏覽次數:4584
日期:2017-07 瀏覽次數:13647
日期:2017-12 瀏覽次數:3508
日期:2018-06 瀏覽次數:4267
日期:2018-05 瀏覽次數:4446
日期:2017-12 瀏覽次數:3558
日期:2017-06 瀏覽次數:3984
日期:2018-01 瀏覽次數:3945
日期:2016-12 瀏覽次數:3915
日期:2018-08 瀏覽次數:4428
日期:2017-12 瀏覽次數:3708
日期:2016-09 瀏覽次數:6406
日期:2018-07 瀏覽次數:3208
日期:2016-12 瀏覽次數:3232
日期:2018-10 瀏覽次數:3386
日期:2018-10 瀏覽次數:3482
日期:2018-09 瀏覽次數:3580
日期:2018-02 瀏覽次數:3600
日期:2015-05 瀏覽次數:3521
日期:2018-09 瀏覽次數:3308
日期:2018-06 瀏覽次數:3435
日期:2017-02 瀏覽次數:3874
日期:2018-02 瀏覽次數:4337
日期:2018-02 瀏覽次數:4176
日期:2016-12 瀏覽次數:3573
Copyright ? 2013-2018 Tadeng NetWork Technology Co., LTD. All Rights Reserved.