主要記錄學習工作流程的筆記

資料

• Http基礎知識學習(四)斑匪，了解HTTPS
• 通俗理解數(shù)字簽名宪拥，數(shù)字證書和https
• https原理通俗了解
• SSL Handshake and HTTPS Bindings on IIS
• SSL/TLS協(xié)議詳解，共有4篇
• 說人話的 HTTPS 協(xié)議簡述——揭秘 Handshake 過程

可以按照先后順序看下

1. 握手前須知

HTTP + 加密 + 認證 + 完整性保護 = HTTPS

HTTPS = HTTP + TLS/SSL鞭呕，TLS是SSL的后繼版本，現(xiàn)在一般都用TLS

SSL是一個二進制協(xié)議，通過443端口進行流量傳輸

為了安全傳輸需要對傳輸內容進行加密杖爽，為了解決各種雞生蛋蛋生雞的問題，HTTPS中使用對稱加密對傳輸內容進行加密紫皇，使用非對稱加密來對對稱加密的密鑰加密

為了防止非對稱加密技術的公鑰被掉包替換慰安，需要數(shù)字證書來保證公鑰的安全性，但由于一個機構要頒發(fā)很多證書聪铺，為了防止證書被篡改化焕，使用數(shù)字簽名技術來驗證數(shù)字證書

可以看看https原理通俗了解

數(shù)字證書 CA

1. 證明公開密鑰本身就是貨真價實的公開密鑰。
2. 證明目標網(wǎng)站是經(jīng)過 CA 驗證的可信任網(wǎng)站

主要包含：

• 對象名稱铃剔，人撒桨、服務器查刻、組織等
• 過期時間
• 證書發(fā)布者，由誰為證書擔保
• 來自證書發(fā)布者的數(shù)字簽名

數(shù)字證書

圖來自 《HTTP 權威指南》

注意：證書自身也有公鑰凤类，服務器也有公鑰穗泵，證書的公鑰為了數(shù)字簽名，服務器的公鑰為了交換對稱算法密鑰

數(shù)字簽名

驗證報文未被偽造或篡改

使用加密系統(tǒng)對報文進行簽名谜疤，可以說明報文的來源佃延，同時又可以驗證報文的完整性

數(shù)字簽名通常是使用非對稱加密技術產(chǎn)生。由于私鑰只有所有者知道夷磕，可以將私鑰作為指紋使用

通過數(shù)字簽名驗證證書

通過數(shù)字簽名驗證證書

圖來自 SSL/TLS協(xié)議詳解履肃，共有4篇

驗證數(shù)字證書，解決同一機構頒發(fā)的不同證書被篡改問題企锌。類比畢業(yè)證的編號

在服務端榆浓，根據(jù)一個Hash算法計算一個證書Hash值，使用證書的私鑰進行加密撕攒，也就是簽名陡鹃。客戶端拿到證書后抖坪，先使用證書公鑰對簽名進行解密得到一個Hash_1萍鲸，然后再次使用證書公鑰根據(jù)指定的算法對證書進行計算，得到Hash_2擦俐，比較兩個Hash值脊阴，相同則認證通過認為證書有效

通過數(shù)字簽名驗證報文完整性

驗證報文

1. 節(jié)點A提取變長報文為定長摘要
2. 節(jié)點A以用戶私鑰為參數(shù)使用一個簽名函數(shù)對摘要進行計算。計算出簽名后蚯瞧，節(jié)點A附加在報文末端嘿期，之后將報文和簽名發(fā)給B
3. 節(jié)點B接收到使用私鑰加密后的簽名，使用公鑰的反函數(shù)埋合，得到摘要信息备徐，之后比較摘要版本信息

在RSA的加密系統(tǒng)中，解碼函數(shù)D已包含私鑰甚颂，可以作用簽名函數(shù)使用

若摘要版本信息不匹配蜜猾，說明報文被篡改或者發(fā)送報文的一端就不是真實的節(jié)點A

2. 握手流程

在整個Handshake過程中，需要完成：

1. 交換協(xié)議版本號
2. 選擇一個兩端都能使用的密碼
3. 對兩端身份進行驗證
4. 生成臨時會話密鑰振诬，以便加密通道

在最終生成的會話密鑰是臨時生成的蹭睡，這樣也保證了前向安全

• 單向認證握手流程

SSL_Handshak

圖來自 SSL Handshake and HTTPS Bindings on IIS

會話發(fā)起時，先進行TCP的3次握手赶么，成功建立連接后肩豁，進行TLS的握手

可以通過Wireshake對GitHub進行抓包，幫助理解學習

GitHub.com 使用 Wireshake 抓包

2.1 第一步，Client Hello

第1步蓖救，Client Hello

圖來自 洪规，Van Bruce大佬的小專欄 說人話的 HTTPS 協(xié)議簡述——揭秘 Handshake 過程

握手第一步，客戶端發(fā)送Hello報文

Client生成一個cRandrom_1循捺，客戶端將cRandrom_1以及TLS版本斩例，自己支持的加密套件列表，會話 id等信息發(fā)送給服務端

cRandrom_1 在生成最終的臨時會話密鑰時會用到

隨機數(shù)是一個32字節(jié)的數(shù)據(jù)从橘。前4個字節(jié)表示epoch 格式的日期念赶，紀元時間是自1970年1月1日以來的秒數(shù)，后28個字節(jié)就是由加密強隨機數(shù)生成器生成的隨機數(shù)

數(shù)據(jù)是明文發(fā)送

使用Wireshark通過Chrome對Github進行抓包恰力，過濾捕獲

GitHub, Client Helllo

TLS版本是1.2

Random就代表著客戶端生成的cRandrodm_1數(shù)據(jù)

第一次進行TLS握手叉谜，Session ID為空

支持的加密套件列表中有19個

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

表示：

使用ECDHE算法交換密鑰，RSA進行簽名或者公鑰驗證身份踩萎，AES_128_GCM加密傳輸數(shù)據(jù)停局，SHA256來驗證數(shù)據(jù)完整性

ECDHE是ECDH的繼生版本，支持前向安全性香府，也就是生成的是臨時的密鑰董栽。ECDH是基于橢圓曲線的加密算法

ECDH和DH算法的目的都是用于交換密鑰而不是加解密，但ECDH比DH破解難度更大

關于密鑰交換企孩，可以看看SSL/TLS協(xié)議詳解(上)：密碼套件锭碳，哈希，加密勿璃，密鑰交換算法了解下

AES_128_GCM稱為批量加密算法擒抛，這里表示AES是一個常用的對稱加密算法，密鑰長度為128补疑，采用GCM模式

AES是 塊密碼歧沪，也就是對輸入的純文本用固定長度的塊來進行加密，加密后的每個塊按再順序發(fā)送莲组，最后按類似的方式來進行解密

關于這些加密算法槽畔，目前只求個面熟，了解下目的

2.2 第二步胁编，Server Hello

第2步，Server Hello

當服務端收到Client Hello后鳞尔，必須要發(fā)送Server Hello信息

服務器先進行檢查TLS版本嬉橙，以及客戶端算法的條件

如果服務器能接受并支持所有條件，將會發(fā)送證書及其他信息寥假；否則市框，服務器會發(fā)送握手失敗信息

過程中，服務端會生成 第二個隨機數(shù)sRandrom_2糕韧，并確認出具體的加密方法枫振，這些信息在下一步會隨證書一起發(fā)給客戶端

服務器生成的sRandrom_2也是32字節(jié)喻圃，但前4字節(jié)表示服務器的Unix紀元時間

證書中包含有服務器的公鑰

這一步中，數(shù)據(jù)也是明文的

所有的服務器都不會在這一步發(fā)送證書

GitHub , ServerHelllo

服務器響應0x0303表示服務器同意使用TLS 1.2

服務器端這時已經(jīng)確定并發(fā)送給了客戶端具體的加密套件

服務器端會生成Session id粪滤，發(fā)送給客戶端后斧拍，客戶端會寫入約定的參數(shù)到此Session id，并給定過期時間

再次發(fā)起會話時杖小，客戶端將在Client Hello中包含此Session id

若客戶端在到期時間之前再次連接到服務器肆汹，則服務器可以檢查Session id對應的緩存參數(shù)，并重用它們而無需完全握手

Cipher suite是兩端約定好的加密算法

2.3 第三步予权，服務端發(fā)送證書昂勉，并進行服務器密鑰交換(可選)

服務器密鑰交換(Server Key Exchange)是可選的，GitHub.com中扫腺，有這個操作岗照，這和GitHub支持的密碼套件有關

GitHub 第三步抓包

2.3.1 Certificate 證書信息

進行完成第二步，服務器會先進行Certificate握手笆环，也就是向客戶端發(fā)送證書

通過抓包攒至，證書消息共3078字節(jié)，這是GitHub.com所有服務器信息的證書咧织。服務器按信任鏈的順序發(fā)送完整的證書列表

該鏈中的第一個是服務器證書嗓袱，接著是頒發(fā)服務器證書的intermediate CA的證書,然后是下一個intermediate CA的證書......直到Root CA的證書。服務器不可以發(fā)送Root CA證書习绢，因為在大多數(shù)情況下渠抹，瀏覽器可以從任何intermediate CA識別Root CA

對于GitHub來說，使用SHA256來生成Hash值闪萄，RSA用于簽名

2.3.2 服務器密鑰交換 Server Key Exchange

為什么 GitHub 必須要這一步驟梧却？

在第二步，GitHub選擇的Session的密碼套件是TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

客戶端和服務器端使用ECDHE(Elliptic Curve Diffie Hellman)來進行交換密鑰败去，由于在DH(Diffie-Hellman)中放航，客戶端無法自行計算生成預主密鑰(Pre-master secret)，需要從服務端獲取DH的公鑰圆裕，服務器便單獨在這個握手中發(fā)送公鑰

服務器密鑰交換完成之后广鳍，再發(fā)送一個Server Helloe Done消息進行通知，客戶端接到后開始準備計算Pre-Master Secret

2.4 第四步吓妆，客戶端證書驗證赊时，密鑰交換，向服務器發(fā)送測試加密數(shù)據(jù)

第4步行拢，生成Pre-Master Secret

接到服務端證書后祖秒，客戶端先根據(jù)證書攜帶的信息對證書進行驗證，證書驗證通過后，客戶端再生成第三個隨機數(shù)cRandrom_3竭缝，這個隨機數(shù)做為預主密鑰(Pre-Master Secret)

到了此時房维，兩端一共產(chǎn)生了3個隨機數(shù)，這個時候客戶端知道cRandrom_1抬纸，sRandRom_2以及用來做為Pre-Master Secret的cRandrom_3咙俩，但服務器端此時還不知道cRandrom_3

為了讓服務器端也知道Pre-Master Secret，需要先進行密鑰交換

看下GitHub.com握手情況

GitHub.com松却，第4步

2.4.1 密鑰交換

客戶端進行密鑰交換時暴浦，根據(jù)約定RSA及DH類算法分兩種情況

RSA是直接加密 Pre-Master Sercet 后發(fā)送到服務端，DH類是需要以 Pre-Master Sercet 為參數(shù)進行計算晓锻，傳遞的是客戶端生成 Pre-Master Sercet 的共享公鑰

若兩端問候(Hello)階段約定好的是用RSA進行交換密鑰歌焦，服務器端已有對應的私鑰，客服端在接到證書后砚哆，隨機生成48字節(jié)的Pre-Master Sercet独撇，之后使用服務器端的公鑰對Pre-Master Sercet加密，發(fā)送到服務端

若約定好的是DH類算法躁锁，像DHE,ECDHE和RSA不同纷铣，DH類算法并非加解密算法，是密鑰協(xié)商算法

GitHub.com使用的是ECDHE來進行交換密鑰战转，服務端在第3步的Server Key Exchange握手前計算生成了服務器端的公-私密鑰對搜立，并把公鑰在Server Key Exchange握手階段，發(fā)送給客戶端槐秧，通知客戶端后面需要進行私鑰交換

客戶端接收到服務器端的公鑰后啄踊，使用自身的公-私鑰，以Pre-Master Sercet為參數(shù)進行計算刁标，得到一個共享密鑰颠通，然后在Client Key Exchange發(fā)送給服務端

客戶端自身也會通過cRandrom_1 + sRandrom_2 + PreMaster Sercet計算 Master Sercet，但 Master Sercet還不是最終用來加密的對稱密鑰

得到Master Sercet后膀懈，再經(jīng)過一系列復雜計算后顿锰，最終生成用于對稱加密的Session Key，SessionKey 是一組隨機數(shù)

ECDHE算法流程文字描述如下:

1. 客戶端隨機生成隨機值Ra启搂，計算Pa(x, y) = Ra * Q(x, y)硼控，Q(x, y)為全世界公認的某個橢圓曲線算法的基點。將Pa(x, y)發(fā)送至服務器
2. 服務器隨機生成隨機值Rb胳赌，計算Pb(x,y) - Rb * Q(x, y)牢撼。將Pb(x, y)發(fā)送至客戶端
3. 客戶端計算Sa(x, y) = Ra * Pb(x, y)；服務器計算Sb(x, y) = Rb *Pa(x, y)
4. 算法保證了Sa = Sb = S匈织，提取其中的S的x向量作為密鑰（預主密鑰）

摘自TLS/SSL 協(xié)議詳解 (30)

2.4.2 Change Cipher Spec，Encrypted_Handshake_Message

當客戶端發(fā)送了共享密鑰后，計算出加密用的對稱密鑰后缀匕，客戶端發(fā)送Change Cipher Spec握手消息通知服務器之后的消息都是加密的

接著纳决，客戶端便根據(jù)之前所有握手消息的信息，計算出一個Hash值乡小，并使用協(xié)商出的加密算法加密阔加，發(fā)送給服務端

2.5 第五步，服務器還原 Premaster Secret满钟，并回復加密測試驗證消息

第5步胜榔，服務器還原 Premaster Sercet

服務器根據(jù)算法，還原出Premaster Secret湃番，這時服務器也擁有了cRandrom_1 + sRandrom_2 + PreMaster Sercet夭织，也可以根據(jù)協(xié)商，計算出最終的對稱加密用Session key

注意：在計算得到 Master Sercet 后吠撮，客戶端和服務端都會刪除各自的私鑰

GitHub.com 握手第5步

同客戶端一樣尊惰，完成一系列操作，生成Session key后泥兰，計算出之前所有握手消息的Hash值弄屡，并將客服端發(fā)來的加密信息解密出來，進行比對校驗鞋诗，驗證密鑰和數(shù)據(jù)的正確性

驗證通過后膀捷，服務端結合當前所有握手消息的信息計算Hash值，再使用自己生成的對稱密鑰加密削彬，發(fā)送給客戶端

當客戶端接收到服務端的Encrypted_Handshake_Message后全庸，對密鑰和數(shù)據(jù)校驗通過時，意味著握手階段結束吃警，之后便是進行加密通信

加密通信

大致的握手流程就是這些

3. 補充

本篇中是以GitHub來抓包幫助學習的糕篇，是單向認證

證書是靜態(tài)的，為了保證密鑰的隨機酌心，加入Pre Master Sercet做為一種隨機因子拌消。然而單單一個Pre Master Sercet還不足以完全隨機，采用cRandrom_1 + sRandrom_2 + PreMaster Sercet
三個隨機數(shù)來使密鑰更加隨機安券，更難暴力破解

在整個握手過程中墩崩，最終加密用到的對稱密鑰是不會在兩端進行傳輸?shù)摹鬏數(shù)闹皇?code>3個隨機數(shù)侯勉，其中前兩個隨機數(shù)是明文傳輸鹦筹，而最后一個是加密傳輸?shù)?/p>

在計算出Master Sercet后，會將兩端各自的私鑰進行刪除

關于會話緩存過程址貌，可以看看HTTPS協(xié)議詳解(四)：TLS/SSL握手過程

再看下铐拐，整個握手流程

整個握手流程

4. 最后

很多地方還不懂徘键，先把了解的記錄下，這次的學習了解收獲還是挺多的遍蟋。Wireshake這個軟件也剛學會一點吹害，以后多用用，能幫助理解

應該會有很多錯誤的地方虚青，希望比較熟悉HTTPS的同學它呀，指出來