一墨辛、相關知識

(一) 密鑰交換算法

TLS 中密鑰交換算法有6種：無效（沒有密鑰交換）躲因、RSA棘伴、匿名Diffie-Hellman晌区、暫時Diffie-Hellman摩骨、固定Diffie-Hellman、Fortezza朗若。

RSA 和 ECDHE 是最常用的兩個密鑰交換算法恼五。

RSA密鑰協(xié)商

1. Client 發(fā)送 Server 的 "Client Hello" 報文中帶有隨機數(shù) Random_1；
2. Server 發(fā)送 Client 的 "Server Hello" 報文中帶有隨機數(shù) Random_2哭懈；
3. Client 用過 RSA 算法隨機生成 Pre-Master Secret灾馒，并且用服務器公鑰加密，包含在"Client Key Exchange" 中發(fā)送給 Server遣总；
4. Client 和 Server 通過 Random_1睬罗、Random_2 和 Pre-Master Secret 通過偽隨機數(shù)函數(shù) PRF 生成 Master Secret。

image

ECDHE密鑰協(xié)商

1. Client 發(fā)送 Server 的 "Client Hello" 報文中帶有隨機數(shù) Random_1旭斥，同時包括兩個 Extension "elliptic_curves" 和 "ec_point_formats"容达；
2. Server 發(fā)送 Client 的 "Server Hello"，包含一個隨機數(shù) Random_2及 ECC 擴展垂券；
3. Server 發(fā)送 Client 證書花盐；
4. Server 生成 ECDH 臨時公鑰，發(fā)送 "Server Key Exchange"，包含三部分重要內容：ECC 相關的參數(shù)算芯、服務器生成的 ECDH 臨時公鑰柒昏、ECC 參數(shù)和公鑰生成的簽名值。
5. Client 驗證證書合法性熙揍，獲取服務器生成的 ECHD 臨時公鑰計算出正式的對稱加密密鑰职祷；
6. Client 生成客戶端 ECHD 臨時公鑰，發(fā)送 "Client Key Exchange"届囚，與上面不同的是堪旧，這個 ECHD 臨時公鑰不需要加密；
7. Server 收到客戶端 ECHD 臨時公鑰后計算出正式的對稱加密密鑰奖亚；

(二) X.509

其實數(shù)字證書并沒有一個全球統(tǒng)一的標準淳梦，但是現(xiàn)在大多數(shù)證書都使用著一個標準的形式X.509 v3。下面列表包括了證書的主要字段：

不清晰的話通過抓包一個真實的證書來對比一下

image

版本 version: v3
序列號 serialNumber: 0x040000000001444ef04247
簽名算法ID signature: Algorithm Id: 1.2.840.113549.1.1.11 (sha256WithRSAEncryption) // 用RSA加密的Sha256摘要
...

(三) 數(shù)字證書的生成

如果我是一家公司压语，我需要申請受信任的證書頒發(fā)機構給我認證，需要提供哪些信息编检。

1. 你公司的信息胎食，包括地區(qū)、公司或組織名稱等允懂；
2. 你需要生成一個自己的公鑰厕怜；
3. 頒發(fā)機構會將這些信息通過散列算法計算出一個摘要，用頒發(fā)機構的私鑰進行加密（也就是簽名）;
4. 一個屬于你公司的數(shù)字證書就生成了蕾总。

Q&A

1. 受信任的頒發(fā)機構的根證書是怎么來的粥航？

A: 頒發(fā)機構沒有上一級頒發(fā)機構，他們的數(shù)字簽名是通過自己的私鑰來簽名的生百。

2. 一定要找收信任的頒發(fā)機構簽名證書嗎递雀？

A: 不一定，也可以自己給自己簽發(fā)一個證書置侍，但是由于瀏覽器只內置了受信任的頒發(fā)機構的根證書映之，如果自己作為一個頒發(fā)機構給自己簽名，瀏覽器會彈出不信任蜡坊，但是整個傳輸過程仍然是安全的杠输。舉個例子：12306就是這么干的。

(四) 信任鏈

數(shù)字證書的頒發(fā)其實就是上一個機構A用A的私鑰為待頒發(fā)的機構的數(shù)字證書簽名秕衙，所以信任鏈的概念也比較明顯蠢甲。

假如A是受信任的頒發(fā)機構，B的證書是由A頒發(fā)的据忘，而B為C的數(shù)字證書簽了名鹦牛，當服務器C請求瀏覽器安全傳輸時，因為A是被瀏覽器信任的勇吊，而A信任了B曼追，B又信任了C，所以瀏覽器是信任C的汉规。

Q&A

1. C請求安全傳輸時礼殊，瀏覽器如何驗證它的證書？

A: 因為瀏覽器只內置了受信任的頒發(fā)機構A的根證書晶伦，所以C需要帶上B的數(shù)字證書啄枕，否則驗證無法通過婚陪。

2. 信任鏈是否可以無限長频祝？

A: 不是泌参，信任鏈有最大支持長度。

二、HTTPS 抓包分析

首先我們來一張圖看完整個 SSL/TLS 握手過程为狸，后面一步一步地抓包分析病曾。

image

以訪問 百度 為例子是牢，用 Wireshark 抓取 Https 包分析批什，本次抓包先清除了瀏覽器緩存。

image

(一) Client -> Server

image

第一步客戶端向服務器發(fā)送 "Client Hello" 信息源织，其中包括了一些字段重點介紹一下：

Client Hello

• Version 協(xié)議版本號

說明了使用的 SSL/TLS 協(xié)議版本號侠仇。

• Random 隨機數(shù)

隨機數(shù)的前4個字節(jié)是當前的協(xié)調世界時鐘的 Unix 時間戳余素，后面緊接28個字節(jié)的隨機數(shù)洛搀，總共32個字節(jié)独榴。

• Session ID 會話標識

作用是客戶端和服務器短時間斷連后谭梗，可以幫助找回之前的會話，而不需要重新進行握手例诀。首次連接時該字段為空爆土。

• Cipher Suite 密碼套件

告知服務器當前客戶端所支持的密碼算法的列表盅抚，可見圖中的列表列舉了16種密碼算法方式壤巷。

• Compression method 壓縮方法

告知服務器當前客戶端支持的壓縮方法檀训，一般不在 TLS層壓縮，圖中為null。

• Extension 擴展

圖中列出了很多擴展苟翻，我選擇幾個重點說明，以后學習到新的我也會補充：

• server_name

指示當前訪問的域名，服務器可能需要部署多個獨立的網(wǎng)站澈魄，但是IP地址卻是同一個景鼠，這樣無法正確找到對應的證書仲翎，所以需要指示出當前請求的域名痹扇，服務器匹配正確的證書。

• sessionTicket TLS (圖中未出現(xiàn))

image

它的出現(xiàn)主要是為了解決 Session ID 在服務器端緩存的壓力溯香，Session Ticket 保存在客戶端并且由服務器密鑰進行加密鲫构。如果客戶端支持Session Ticket，在 TLS 握手的最后一步中服務器將包含一個 "New Session Ticket" 信息玫坛。

• Application Layer Protocol Negotiation (ALPN 應用層協(xié)議協(xié)商)

image

在 TLS 握手期間结笨，客戶端和服務器商議使用的應用層協(xié)議，如果服務器不支持客戶端要求的協(xié)議則中止連接湿镀。

• signature algorithms 簽名算法

image

指明簽名可以使用的哈希算法炕吸。

總得而言，"Client Hello" 就是客戶端和服務器在進行協(xié)商勉痴，如果服務器能接受赫模，則繼續(xù)；不能接受蒸矛，則中止握手瀑罗。

(二) Server -> Client

如果報文有 Session ID，服務器通過對 ID 進行校驗雏掠，如果成功則直接恢復之前的會話斩祭。如果沒有 ID，服務器將保存客戶端生成的隨機數(shù)乡话，在密碼套件中選擇使用的密碼套件摧玫。

image

第二步，服務器向客戶端發(fā)送 "Server Hello" 信息绑青，其中包括了：

• 隨機數(shù) Random

服務器根據(jù)相同的生成規(guī)則生成一個隨機數(shù)席赂。

• 密碼套件 Cipher Suite

從客戶端的套件列表中選取一個套件并告知客戶端吮铭。

緊接著發(fā)送 Certificate 證書和 "Server Hello Done"信息：

image

Server Key Exchange

服務器密鑰交換。

Server Hello Done

表示 SSL/TLS 握手結束颅停。

(三) Client 校驗證書合法性

1. 判斷證書是否在有效期內谓晌；
2. 簽名頒發(fā)者可信度檢測癞揉，沿著信任鏈向根證書驗證該證書的合法性纸肉，直到找到一個客戶端信任的證書頒發(fā)機構喊熟，否則驗證失敗芥牌；
3. 通過用頒發(fā)機構的公鑰解密簽名烦味，與證書的散列比較壁拉，如果不相等，驗證失斊怼溃论；
4. 站點身份檢測，為防止服務器復制其他人的證書痘昌，大部分瀏覽器都會去驗證證書中的域名與它們所對話的服務器的域名是否匹配。

(四) Client -> Server

Client Key Exchange

image

客戶端密鑰交換算灸。

Change Clipher Spec

image

不管是DH算法還是RSA算法菲驴，此時客戶端都可以計算出正確的Master Secret（加密傳輸所使用的對稱加密秘鑰）街佑，所以 "Change Clipher Spec" 是客戶端告知服務器開始使用加密方式發(fā)送報文和 MAC 計算。

Encrypted Handshake Message (Finished)

image

對之前握手的所有信息用 Master Secret 進行加密后傳輸森逮，防止被篡改磁携，同時驗證加密傳輸是否可用。

(五) Server -> Client

image

服務器收到客戶端報文后計算出相同的 Master Secret闷供，發(fā)送"Change Clipher Spec" 和 "Encrypted Handshake Message"。

三疑俭、再次抓包

間隔一段時間婿失，對百度首頁再次抓包

image

可以發(fā)現(xiàn) Session ID 字段有了一個32字節(jié)長度的值，再看看整個 SSL/TLS 握手過程發(fā)現(xiàn)了什么變化：

image

握手過程減少了不少哩照，可見 Session ID 的存在使得客戶端和服務器恢復了之前的會話懒浮，它們之間采用了之前的加密密鑰繼續(xù)進行加密傳輸。

四次伶、補充

(一) 密碼套件分析

從抓包結果赖草，解讀一下密碼套件的含義：

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

• 基于TLS協(xié)議
• 用ECDHE_RSA做密鑰交換算法
• 用AES_128_CBC做內容的對稱加密算法
• 用SHA256做MAC算法

算法種類

• 密鑰交換算法剪个，用于決定客戶端與服務器之間在握手的過程中如何認證，用到的算法包括RSA乎折，Diffie-Hellman侵歇，ECDH，PSK等
• 對稱加密算法坟冲，用于加密消息流溃蔫，該名稱后通常會帶有兩個數(shù)字，分別表示密鑰的長度和初始向量的長度私痹，比如DES 56/56, RC2 56/128, RC4 128/128, AES 128/128, AES 256/256
• 報文認證信息碼(MAC)算法，用于創(chuàng)建報文摘要账千，確保消息的完整性暗膜，算法包括MD5，SHA等攒射。
• PRF（偽隨機數(shù)函數(shù)）用于生成"Master Secret"恒水。

(二) MAC

TLS協(xié)議還提供了它自己的消息分片機制，且采用消息認證碼（MAC）對每一個分片消息進行簽名咧最。MAC算法是一個單向的哈希加密函數(shù)（一個非常高效的校驗碼）御雕，HASH函數(shù)密鑰由兩端進行協(xié)商酸纲。每當一個TLS記錄被發(fā)送，生成的MAC值闽坡，將附加在該消息中疾嗅，接收端采用相同的方法計算和驗證所發(fā)送的MAC值，以確保消息的完整性和真實性代承。

(三) SNI

SNI 全稱Server Name Indication
论悴，如果服務器需要部署多個獨立的網(wǎng)站，每個與自己的TLS證書膀估，但使用同一個IP地址玖像。
為了解決上述問題齐饮，SNI 擴展被引入到 TLS 協(xié)議中笤昨，它允許客戶端在握手開始指示他想要連接的主機名。服務器檢查SNI主機名捺僻，選擇適當?shù)淖C書崇裁，并繼續(xù)握手。
TLS葛峻，HTTP和專用IP

(四) TLS壓縮

一個鮮為人知的TLS特性就是在其紀錄協(xié)議中已經內置支持無損數(shù)據(jù)壓縮：壓縮算法在TLS握手過程中協(xié)商巴比，數(shù)據(jù)在加密應用之前進行壓縮轻绞。然而，在實際應用中政勃，你應該在你的服務器上禁用TLS壓縮奸远，有以下幾個原因：

• "CRIME"攻擊，在2012年被公布然走，利用TLS壓縮來恢復身份驗證的Cookie芍瑞，并允許攻擊者進行會話劫持褐墅；
• TLS壓縮屬于傳輸層壓縮，他無法感知數(shù)據(jù)內容竟贯，他將去重復壓縮已壓縮的數(shù)據(jù)（比如圖片逝钥，視頻等）。重復壓縮會同時在服務器和客戶端浪費CPU時間持际。

另外，安全漏洞的影響也是相當?shù)膰乐匾婷迹虼诵枰脡嚎sTLS姥份。在實際應用中，大多數(shù)的瀏覽器都是禁用TLS壓縮的展鸡，不過埃难，你應該明確的在您的服務器上明確的禁用凯砍，以保護您的用戶。

相反悟衩，我們不應該依賴于TLS的壓縮座泳，而是應該在應用層配置Gzip，使所有文本型資源采用gzip方式傳輸镇防，而對其他格式如圖像潮饱，視頻和音頻應該去選取最佳的壓縮格式。