本文借助wireshark抓包詳細(xì)的講解SSL/TLS協(xié)議。HTTPS是為了解決http報(bào)文明文傳輸過程中的安全問題。HTTPS是“HTTP over SSL”的縮寫。所以要了解HTTPS就必須先了解SSL/TLS協(xié)議。

一、HTTP協(xié)議的風(fēng)險(xiǎn)

HTTP協(xié)議中所有消息都是明文傳播，存在如下三大風(fēng)險(xiǎn)

1. 竊聽風(fēng)險(xiǎn)（eavesdropping）：第三方可以獲知通信內(nèi)容。
2. 篡改風(fēng)險(xiǎn)（tampering）：第三方可以修改通信內(nèi)容。
3. 冒充風(fēng)險(xiǎn)（pretending）：第三方可以冒充他人身份參與通信。

為了解決這個(gè)三個(gè)風(fēng)險(xiǎn)，分別對(duì)應(yīng)如下三個(gè)解決方案。

1. 加密：所有信息都是加密傳播，第三方無法竊聽。
2. 校驗(yàn)：具有校驗(yàn)機(jī)制，一旦被篡改，通信雙方會(huì)立刻發(fā)現(xiàn)。
3. 身份驗(yàn)證：配備身份證書，防止身份被冒充。

二、SSL/TLS 發(fā)展歷史

1. 1994年，NetScape公司設(shè)計(jì)了SSL協(xié)議（Secure Sockets Layer）的1.0版，但是未發(fā)布。
2. 1995年，NetScape公司發(fā)布SSL 2.0版，很快發(fā)現(xiàn)有嚴(yán)重漏洞。
3. 1996年，SSL 3.0版問世，得到大規(guī)模應(yīng)用。
4. 1999年，互聯(lián)網(wǎng)標(biāo)準(zhǔn)化組織ISOC接替NetScape公司，發(fā)布了SSL的升級(jí)版TLS 1.0版。
5. 2006: TLS 1.1. 作為 RFC 4346 發(fā)布。主要fix了CBC模式相關(guān)的如BEAST攻擊等漏洞。
6. 2008: TLS 1.2. 作為RFC 5246 發(fā)布 。增進(jìn)安全性。目前(2015年)應(yīng)該主要部署的版本。
7. 2015之后: TLS 1.3，還在制訂中，支持0-rtt，大幅增進(jìn)安全性，砍掉了aead之外的加密方式。

由于SSL的2個(gè)版本都已經(jīng)退出歷史舞臺(tái)了，所以本文后面只用TLS這個(gè)名字。 一般所說的SSL就是TLS。

三、報(bào)文解析(rfc5246)

TLS建立連接的過程如下圖，先有個(gè)大概的印象，后面我們?cè)僭敿?xì)分析。整個(gè)需要四次握手。

TLS認(rèn)證過程

SSL/TLS工作在應(yīng)用層和傳輸層之間，在建立連接的之前需要先建立TCP連接（三次握手），如下圖。

TLS協(xié)議抓包

3.1 詳細(xì)過程

（1）Client Hello

Client Hello

3.1.1 記錄協(xié)議（Record Layer）

記錄協(xié)議根據(jù)rfc描述記錄協(xié)議（Record Layer）有如下4種類型，即上圖中Content Type可以取的值。

record layer

記錄協(xié)議（Record Layer） 數(shù)據(jù)結(jié)構(gòu)

Record layer數(shù)據(jù)結(jié)構(gòu)

3.1.2 握手協(xié)議（Handshake Protocal）

握手協(xié)議（Handshake Protocal）有如下10種類型。

Handshake Protocal

握手協(xié)議（Handshake Protocal）數(shù)據(jù)結(jié)構(gòu)

image.png

3.1.3 客戶端支持的加密套件（Cipher suite）

wireshark抓包顯示客戶端支持的加密套件有31種。cipher的格式為：認(rèn)證算法密鑰交換算法加密算法_ 摘要算法。server會(huì)從這些算法組合中選取一組，作為本次SSL連接中使用。

cipher suite

（2）Server Hello

Server Hello

（3）Certificate、ServerKeyExchange、ServerHelloDone

image.png

1. Certificate
   我們知道https在建立連接的時(shí)候是用的非對(duì)稱加密（RSA），在實(shí)際數(shù)據(jù)傳輸階段是用的對(duì)稱加密（AES等）。非對(duì)稱加密的是需要獲取server段的公鑰的。但是這個(gè)公鑰不是誰生成的都可以用的（存在中間人攻擊）。所以需要專門的機(jī)構(gòu)發(fā)行的證書才行。那么這個(gè)證書就是這里的Certificate，公鑰就藏在里面。

2. ServerKeyExchange

   
   
   image.png

這個(gè)包告訴我們服務(wù)器和客戶端是通過Diffie-Hellman算法來生成最終的密鑰（也就是Sessionkey會(huì)話密鑰），pubkey是Diffie-Hellman算法中的一個(gè)參數(shù)，這個(gè)參數(shù)需要通過網(wǎng)絡(luò)傳給客戶端，即使它被截取也不會(huì)影響安全性。具體見參考文獻(xiàn)三。
在client hello和server hello包中都有Random字段，上面我們是沒有說明的，client和server這兩個(gè)隨機(jī)數(shù)加Diffie-Hellman算法生成出來的這個(gè)key。一共三個(gè)數(shù)字生成最終對(duì)稱加密的key

3. ServerHelloDone
   根據(jù)rfc描述，ServerHelloDone發(fā)送完后，等待client回復(fù)，client需要驗(yàn)證證書

   
   
   image.png

（4）Client Key Exchange、Change Cipher Spec、Encrypted Handshake Message(Finishd)

image.png

1. Client Key Exchange
   客戶端收到服務(wù)器發(fā)來的ServerKeyExchange包來之后，運(yùn)行Diffie-Hellman算法生成一個(gè)pubkey，然后發(fā)送給服務(wù)器。通過這一步和上面ServerKeyExchange兩個(gè)步驟，服務(wù)器和客戶端分別交換了pubkey，這樣他們就可以分別生成了一個(gè)一樣的sessionkey

2. Change Cipher Spec
   指示Server從現(xiàn)在Client開始發(fā)送的消息都是加密過的

3. Encrypted Handshake Message
   client發(fā)送encrypted handshake message, server如果解密沒有問題，那么說明之前發(fā)送到數(shù)據(jù)沒有被篡改。

（5）Change Cipher Spec、Encrypted Handshake Message(Finishd)

1. Change Cipher Spec
   指示client從現(xiàn)在Server開始發(fā)送的消息都是加密過的
2. Encrypted Handshake Message
   與client發(fā)送的Encrypted Handshake Message目的一樣

（6）Application Data

Application Data

從現(xiàn)在開始發(fā)送的數(shù)據(jù)就是采用上述步驟協(xié)商出的對(duì)稱加密密鑰加密過的數(shù)據(jù)了

3.1.4 總結(jié)

再回過頭來看一下這張圖，加密過程總結(jié)如下：

TLS認(rèn)證過程

1. client 發(fā)送ClientHello，攜帶一個(gè)隨機(jī)數(shù)
2. server 發(fā)送ServerHello,攜帶一個(gè)隨機(jī)數(shù)
3. server發(fā)送Certificate，攜帶證書，證書中含有server段的公鑰
4. server和client都發(fā)送了KeyExchange,通過Diffie-Hellman密鑰協(xié)商出一個(gè)key（也相對(duì)于一個(gè)隨機(jī)數(shù)）
5. 通過上面三個(gè)隨機(jī)數(shù)生成一個(gè)key，后面的加密過程都是用的這個(gè)key
6. server和client都會(huì)用生成的key來發(fā)送一條加密后的消息。來驗(yàn)證整個(gè)流程的安全性。

參考文獻(xiàn)

1. SSL/TLS協(xié)議運(yùn)行機(jī)制的概述
2. TLS協(xié)議報(bào)文解析
3. Diffie-Hellman密鑰協(xié)商算法
4. 徹底搞懂HTTPS的加密原理