說(shuō)起TLS（Transport Layer Security) 協(xié)議大家可能不是那么熟悉款票，但是說(shuō)起HTTPS協(xié)議，大家肯定都或多或少聽(tīng)過(guò)岳枷。記得之前有個(gè)梗肌割，要把服務(wù)器的應(yīng)用層協(xié)議從HTTP切到HTTPS声滥，有人說(shuō)了眉撵，加個(gè)“S”不就可以了，一句話的事情……醒串，實(shí)際上我一開(kāi)始我也以為HTTPS只不過(guò)比HTTP多了一個(gè)“S”而已执桌，這句話還真毛病鄙皇，但并不是簡(jiǎn)單的在后面加個(gè)“S”就完事了芜赌，實(shí)際上這里的“S”就是我們今天要介紹的TLS協(xié)議。

TLS協(xié)議的前身是SSL協(xié)議伴逸，后者的全稱是 Socket Security Layer缠沈，可以看到兩者都涉及到了安全，實(shí)際上TLS協(xié)議的目標(biāo)就是解決以下幾個(gè)問(wèn)題：

**信息被竊聽(tīng)(wiretap)错蝴，第三方隨時(shí)隨地獲得通訊內(nèi)容洲愤；

SSL/TLS 實(shí)現(xiàn)了傳輸信息的加密。

數(shù)據(jù)被篡改(tampering)顷锰，第三方可修改傳輸中的數(shù)據(jù)柬赐；

SSL/TLS 實(shí)現(xiàn)了數(shù)據(jù)簽名及校驗(yàn)。

身份被冒充(pretending)官紫，第三方可冒充通訊者身份傳輸數(shù)據(jù)肛宋；

SSL/TLS 采用了CA數(shù)字證書(shū)認(rèn)證機(jī)制。**

我們今天就從理論層面束世、生產(chǎn)環(huán)節(jié)下的實(shí)際表現(xiàn)以及chromium的代碼實(shí)現(xiàn)這三個(gè)維度來(lái)詳細(xì)地分析TLS協(xié)議酝陈，看看它究竟是如何實(shí)現(xiàn)上面這三方面的。

關(guān)于TLS協(xié)議的過(guò)程毁涉，大家肯定都知道TCP的三次握手沉帮，TLS也有類(lèi)似的握手過(guò)程，和TCP為了建立穩(wěn)定連接才進(jìn)行握手類(lèi)似贫堰，TLS協(xié)議也要進(jìn)行客戶端與服務(wù)端之間的通信穆壕，而通信的內(nèi)容，就是在整個(gè)TLS協(xié)議中最為重要的密鑰其屏。這里的密鑰是客戶端和服務(wù)端動(dòng)態(tài)生成喇勋，然后通過(guò)信息交互的方式保持一致，在這里涉及到很多安全學(xué)和密碼學(xué)的知識(shí)漫玄，例如各種加密算法茄蚯，動(dòng)態(tài)密鑰算法等等压彭，有興趣的同學(xué)可以去關(guān)注一下這方面的知識(shí)，在這里就不再贅述了渗常。大致的握手流程如下：

客戶端發(fā)出一個(gè) client hello 消息壮不，攜帶的信息包括：

所支持的SSL/TLS 版本列表；支持的加密算法皱碘；所支持的數(shù)據(jù)壓縮方法询一；客戶端生成的隨機(jī)數(shù)A;

服務(wù)端響應(yīng)一個(gè) server hello 消息，攜帶的信息包括：

協(xié)商采用的SSL/TLS 版本號(hào)癌椿；會(huì)話ID健蕊；服務(wù)器端生成的隨機(jī)數(shù)B；服務(wù)端數(shù)字證書(shū) serverCA踢俄；

由于雙向認(rèn)證需求缩功，服務(wù)端需要對(duì)客戶端進(jìn)行認(rèn)證，會(huì)同時(shí)發(fā)送一個(gè) client certificate request都办，表示請(qǐng)求客戶端的證書(shū)嫡锌；

客戶端校驗(yàn)服務(wù)端的數(shù)字證書(shū)；校驗(yàn)通過(guò)之后發(fā)送隨機(jī)數(shù)C琳钉，該隨機(jī)數(shù)稱為pre-master-key势木，使用數(shù)字證書(shū)中的公鑰加密后發(fā)出；

由于服務(wù)端發(fā)起了 client certificate request歌懒，客戶端使用私鑰加密一個(gè)隨機(jī)數(shù) clientRandom隨客戶端的證書(shū) clientCA一并發(fā)出啦桌；

服務(wù)端校驗(yàn)客戶端的證書(shū)，并成功將客戶端加密的隨機(jī)數(shù)clientRandom 解密及皂；

根據(jù)隨機(jī)數(shù)A/隨機(jī)數(shù)B/隨機(jī)數(shù)C(pre-master-key) 產(chǎn)生動(dòng)態(tài)密鑰 master-key甫男，加密一個(gè)finish 消息發(fā)至客戶端；

客戶端根據(jù)同樣的隨機(jī)數(shù)和算法 生成master-key躲庄，加密一個(gè)finish 消息發(fā)送至服務(wù)端查剖；

服務(wù)端和客戶端分別解密成功，至此握手完成噪窘，之后的數(shù)據(jù)包均采用master-key進(jìn)行加密傳輸笋庄。

下面這張圖更為直觀地將整個(gè)過(guò)程表現(xiàn)了出來(lái)：

可以看到，整個(gè)過(guò)程至少需要兩個(gè)RTT(往返時(shí)延)才可以完成認(rèn)證倔监，也就是說(shuō)至少要兩個(gè)RTT以后客戶端才可以向服務(wù)端發(fā)送請(qǐng)求直砂，如果再加上TCP三次握手用去的1個(gè)RTT，那么一共就要3個(gè)RTT后才可以進(jìn)行數(shù)據(jù)的傳輸浩习，這顯然大大降低了傳輸效率静暂，因此TLS協(xié)議也在不斷地優(yōu)化其速度，這也是未來(lái)TLS協(xié)議的一個(gè)重要研究方向谱秽，后續(xù)我們講到優(yōu)化的時(shí)候會(huì)著重再講這部分的洽蛀。

相信理論層的知識(shí)摹迷，通過(guò)看圖并結(jié)合文字描述，大多數(shù)人都可以明白基本的道理郊供，當(dāng)然也僅限于淺顯的理論峡碉，拉開(kāi)來(lái)講每部分都很需要花費(fèi)一定時(shí)間才能理解和掌握，這些都留給后續(xù)的章節(jié)再來(lái)細(xì)說(shuō)驮审，下面我們就看看在實(shí)際的生產(chǎn)環(huán)境中TLS協(xié)議是如何工作的鲫寄。

先介紹一下我們的幫手，Wireshark疯淫，一款非常著名的抓包軟件地来，通過(guò)它我們便可以抓取一些我們想要的信息，然后再加以分析熙掺。關(guān)于軟件的下載安裝和使用未斑，大家直接上網(wǎng)搜一下，這里不再贅述适掰，下面我們登陸一個(gè)使用了https協(xié)議的網(wǎng)站颂碧，直接用Wireshark進(jìn)行抓包荠列，得到的部分報(bào)文如下：

這就是一個(gè)典型的三次握手過(guò)程类浪，客戶端發(fā)送SYN報(bào)文，服務(wù)端受到后發(fā)SYN ACK報(bào)文肌似，然后客戶端發(fā)相應(yīng)的ACK回應(yīng)報(bào)文费就，想學(xué)習(xí)TCP的同學(xué)強(qiáng)烈建議你們?nèi)ピ囈幌拢^對(duì)比你看書(shū)學(xué)得更快川队，更牢固力细。

接下來(lái)我們就來(lái)看一下TLS協(xié)議的交換，

直接將所有的TLS報(bào)文過(guò)濾出來(lái)固额，可以看到眠蚂，首先是客戶端發(fā)Client Hello報(bào)文，然后是服務(wù)端接收并且發(fā)送Server Hello報(bào)文斗躏，同時(shí)我們注意到逝慧，服務(wù)器端緊接著又發(fā)送了兩個(gè)報(bào)文，分別是Certificate報(bào)文和Server Key報(bào)文啄糙，這就是前文中提到的一些已經(jīng)經(jīng)過(guò)加密的證書(shū)信息笛臣，當(dāng)客戶端收到這些證書(shū)以后，則發(fā)送相應(yīng)的prr-master-key隧饼，服務(wù)端在接收到這個(gè)key以后沈堡，生成相應(yīng)的master-key值，這樣燕雁，一個(gè)完整的TLS握手協(xié)議過(guò)程就算完成了诞丽，后續(xù)就可以看到客戶端和服務(wù)器之間已經(jīng)開(kāi)始用TLS傳輸加密后的數(shù)據(jù)了鲸拥。

抓取其中的一個(gè)報(bào)文來(lái)看一下：

可以看到TCP下面就是SSL，在這里我們抓取的是Client Hello報(bào)文僧免，也就是客戶端發(fā)起握手協(xié)議后的第一個(gè)報(bào)文崩泡，可以看到這個(gè)報(bào)文包含了不少字段，首先是Content Type字段猬膨，這里的的類(lèi)型是Handshake,也就是握手協(xié)議角撞，還有緊接著跟的是使用的TLS協(xié)議版本號(hào)以及數(shù)據(jù)包的長(zhǎng)度。

接下來(lái)便是Handshake層的具體內(nèi)容了勃痴，幾個(gè)主要字段的含義和相應(yīng)的賦值對(duì)應(yīng)關(guān)系：

Handshake Type ：Client Hello谒所，在這里表示握手協(xié)議的類(lèi)型，一般有這幾種類(lèi)型值：

0) hello_request:

1) client_hello:

2) server_hello:

4) certificate:

5) server_key_exchange:

6) certificate_request:

7) server_done:

8) certificate_verify:

9) client_key_exchange:

10) :

Length ： 508 表示這個(gè)握手協(xié)議的總長(zhǎng)度沛申，注意到TLS的總長(zhǎng)度是512劣领，如果除去TLS頭內(nèi)容的￥字節(jié)，剛好就是508

Version：TLS 1.2 要注意這里的Version是代表客戶端可以支持的最高協(xié)議版本號(hào)铁材，與之前的Version代表的客戶端正在使用的版本號(hào)是有區(qū)別的尖淘。

Random: 客戶端生成的一個(gè)隨機(jī)數(shù) 這就是我們之前提到的客戶端會(huì)生成一個(gè)隨機(jī)數(shù)，然后再發(fā)送到服務(wù)端著觉，作為生成master-key的依據(jù)村生。

除了Handshake之外，TLS報(bào)文還有另外3種類(lèi)型饼丘，分別是:

警告層(Alert): 如果在通信過(guò)程中某一方發(fā)現(xiàn)任何異常趁桃，就需要給對(duì)方發(fā)送一條警示消息通告。

改變密碼格式層（Client Key Exchange): SSL協(xié)議要求客戶端或服務(wù)器端每隔一段時(shí)間必須改變其加解密參數(shù)肄鸽。當(dāng)某一方要改變其加解密參數(shù)時(shí)卫病，就發(fā)送一個(gè)簡(jiǎn)單的消息通知對(duì)方下一個(gè)要傳送的數(shù)據(jù)將采用新的加解密參數(shù)

應(yīng)用數(shù)據(jù)層(Application Data): 進(jìn)行加密后的數(shù)據(jù)傳輸

通過(guò)抓包并分析具體報(bào)文的構(gòu)成，對(duì)于TLS報(bào)文的構(gòu)成應(yīng)該有一個(gè)更為直觀的了解典徘，其中最為關(guān)鍵也是最復(fù)雜的就是握手的過(guò)程蟀苛，以后我們會(huì)對(duì)這部分內(nèi)容做更為深入的分析。

講完了TLS的理論基礎(chǔ)逮诲，也看到了其在實(shí)際生產(chǎn)環(huán)境中一些應(yīng)用帜平，相信對(duì)于這個(gè)協(xié)議也有一個(gè)大致的了解，后續(xù)還會(huì)講到chromium對(duì)于TLS的代碼實(shí)現(xiàn)汛骂，敬請(qǐng)期待罕模。