本文主要對(duì)對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密的原理以及過(guò)程進(jìn)行分析峻凫，同時(shí)還會(huì)簡(jiǎn)單介紹一下TLS/SSL的一些相關(guān)內(nèi)容渗鬼，并且對(duì)比TLSv1.2和TLSv1.3的不同。
1荧琼、SSL和TLS的歷史
其實(shí)早期的互聯(lián)網(wǎng)協(xié)議基本都是不加密進(jìn)行傳輸?shù)钠┨ィ鏗TTP、FTP命锄、telnet.等協(xié)議的
傳輸層安全性協(xié)議（英語(yǔ)：Transport Layer Security堰乔，縮寫(xiě)：TLS）及其前身安全套接層（英語(yǔ)：Secure Sockets Layer，縮寫(xiě)：SSL）的歷史進(jìn)程如下表所示：
| 協(xié)議 | 發(fā)布時(shí)間 | 狀態(tài) |
|---|---|---|
| SSL 1.0 | 未公布 | 未公布 |
| SSL 2.0 | 1995年 | 已于2011年棄用 |
| SSL 3.0 | 1996年 | 已于2015年棄用 |
| TLS 1.0 | 1999年 | 已于2020年棄用 |
| TLS 1.1 | 2006年 | 已于2020年棄用 |
| TLS 1.2 | 2008年 | |
| TLS 1.3 | 2018年 |
SSL（Secure Sockets Layer）是網(wǎng)景公司（Netscape）設(shè)計(jì)的主要用于Web的安全傳輸協(xié)議脐恩，這種協(xié)議在Web上獲得了廣泛的應(yīng)用镐侯。SSL1.0沒(méi)有被公開(kāi)發(fā)布過(guò)，1995 網(wǎng)景公司發(fā)布SSL2.0被盈，但是由于SSL2.0有嚴(yán)重的安全漏洞析孽，因此1996年又發(fā)布了SSL3.0。
但是在2014年10月只怎，Google發(fā)布在SSL 3.0中發(fā)現(xiàn)設(shè)計(jì)缺陷袜瞬，建議禁用此一協(xié)議。攻擊者可以向TLS發(fā)送虛假錯(cuò)誤提示身堡，然后將安全連接強(qiáng)行降級(jí)到過(guò)時(shí)且不安全的SSL 3.0邓尤，然后就可以利用其中的設(shè)計(jì)漏洞竊取敏感信息。Google在自己公司相關(guān)產(chǎn)品中陸續(xù)禁止回溯兼容贴谎，強(qiáng)制使用TLS協(xié)議汞扎。Mozilla也在11月25日發(fā)布的Firefox 34中徹底禁用了SSL 3.0。微軟同樣發(fā)出了安全通告擅这。這就是SSL3.0在2015年被棄用的原因澈魄。但是由于SSL存在的時(shí)間太長(zhǎng)了，人們以及習(xí)慣用SSL這個(gè)名詞來(lái)指代加密的安全傳輸協(xié)議仲翎，因此我們要知道現(xiàn)在說(shuō)的SSL絕大多數(shù)都是說(shuō)的TLS加密痹扇。
眾所周知當(dāng)年的瀏覽器大戰(zhàn)微軟戰(zhàn)勝了網(wǎng)景，而后網(wǎng)景將SSL協(xié)議的管理權(quán)交給了標(biāo)準(zhǔn)化組織IETF（Internet Engineering Task Force）溯香。1999年鲫构，IETF在SSL3.0的基礎(chǔ)上進(jìn)行發(fā)布了TLS協(xié)議的1.0版本，需要注意的是TLS1.0版本和SSL3.0版本的區(qū)別很小玫坛，并且TLS1.0是可以降級(jí)到SSL3.0來(lái)使用的结笨，之所以換名字主要是為了避免一些版權(quán)和法律的問(wèn)題。這也就導(dǎo)致了后來(lái)谷歌禁止TLS回溯兼容SSL協(xié)議從而避免安全事故的發(fā)送。注意其實(shí)所有TLS版本在2011年3月發(fā)布的RFC 6176中刪除了對(duì)SSL2.0的兼容炕吸，這樣TLS會(huì)話將永遠(yuǎn)無(wú)法協(xié)商使用的SSL 2.0以避免安全問(wèn)題伐憾。但是還是可以降級(jí)協(xié)商到SSL3.0的。
RFC 6176的原文摘要如下： This document requires that when Transport Layer Security (TLS) clients and servers establish connections, they never negotiate the use of Secure Sockets Layer (SSL) version 2.0. This document updates the backward compatibility sections found in the Transport Layer Security (TLS).
TLS 1.1在 RFC 4346 中定義算途，于2006年4月發(fā)表塞耕。TLS 1.2在 RFC 5246 中定義，于2008年8月發(fā)表嘴瓤。TLS 1.3在 RFC 8446 中定義扫外，于2018年8月發(fā)表。實(shí)際上現(xiàn)代的瀏覽器已經(jīng)基本不使用 SSL廓脆，使用的都是 TLS筛谚，而目前主流使用的加密協(xié)議版本是TLS1.2和TLS1.3。
2停忿、SSL/TLS屬于哪一層
這個(gè)問(wèn)題十分有意思驾讲，從前面的發(fā)展歷史中我們不難知道，TLS可以視為是SSL的高級(jí)版本（主要體現(xiàn)在更加安全上）席赂，而從TLS的名字（傳輸層安全性協(xié)議）就會(huì)覺(jué)得它應(yīng)該是傳輸層的協(xié)議吮铭，當(dāng)然這可能就望文生義了，實(shí)際上在網(wǎng)上有不少的文章在討論TLS/SSL屬于應(yīng)用層還是傳輸層颅停，實(shí)際上的情況要更為復(fù)雜一些谓晌，我們先來(lái)搞清楚在不同的網(wǎng)絡(luò)模型中對(duì)于不同層的劃分。
首先我們需要知道一般說(shuō)的七層協(xié)議指的是在OSI模型協(xié)議癞揉，而在TCP/IP模型中網(wǎng)絡(luò)被劃分為四層纸肉，我們直接來(lái)看下面的示意圖：
原始版本的OSI模型劃分得太細(xì)，TCP/IP模型又劃分得太粗喊熟，于是人們把兩者結(jié)合柏肪，將OSI模型中的5、6芥牌、7三層統(tǒng)一為應(yīng)用層烦味，就得到了一個(gè)升級(jí)版的五層網(wǎng)絡(luò)模型。
首先我們對(duì)SSL/TLS的作用進(jìn)行分析：SSL/TLS最初是為了給HTTP協(xié)議加密使用壁拉，也就是HTTPS協(xié)議拐叉，通常來(lái)說(shuō)我們可以認(rèn)為HTTP+SSL/TLS=HTTPS，而實(shí)際上現(xiàn)在我們的很多其他應(yīng)用層協(xié)議都可以使用SSL/TLS扇商，比如SSH、FTPS宿礁、POP3S案铺、IMAPS等等。再以HTTPS為例梆靖，一個(gè)HTTPS建立連接需要經(jīng)過(guò)TCP握手建立連接這一步驟的控汉，也就是說(shuō)HTTPS還是基于TCP的笔诵，而TCP屬于傳輸層這是毫無(wú)爭(zhēng)論的。也就是說(shuō)從劃分最細(xì)的OSI七層參考模型來(lái)看姑子，SSL/TLS應(yīng)該是在傳輸層和應(yīng)用層之間乎婿。
實(shí)際上從SSL/TLS的功能來(lái)分析：
- SSL Record Protocol（SSL記錄協(xié)議），它建立在可靠的傳輸協(xié)議（如TCP）之上街佑，SSL/TLS使用了雙向字節(jié)流傳輸（全雙工）谢翎，為高層協(xié)議提供數(shù)據(jù)封裝、壓縮沐旨、加密等基本功能的支持森逮，從功能上看這應(yīng)該是OSI的L6（表示層）
- SSL Handshake Protocol（SSL握手協(xié)議）：它建立在SSL記錄協(xié)議之上，用于在實(shí)際的數(shù)據(jù)傳輸開(kāi)始前磁携，通訊雙方進(jìn)行身份認(rèn)證褒侧、協(xié)商加密算法、交換加密密鑰等谊迄，從功能上看這應(yīng)該是OSI的L5（會(huì)話層）
首先闷供，SSL協(xié)議分為SSL握手協(xié)議和SSL記錄協(xié)議。記錄協(xié)議工作在TCP之上统诺，握手協(xié)議工作在記錄協(xié)議之上歪脏。
而與之相對(duì)應(yīng)的七層結(jié)構(gòu)中，傳輸層之上是會(huì)話層篙议，會(huì)話層之上是表示層唾糯。
一、會(huì)話層負(fù)責(zé)建立和位置會(huì)話鬼贱，很明顯SSL握手協(xié)議就是干這個(gè)事的移怯。
二、表示層對(duì)統(tǒng)一傳輸方式这难，并對(duì)數(shù)據(jù)進(jìn)行加密之類(lèi)的前置處理舟误。這個(gè)應(yīng)該是SSL記錄協(xié)議要做的事情。
所以如果真要說(shuō)對(duì)應(yīng)關(guān)系姻乓，應(yīng)該是SSL握手協(xié)議對(duì)應(yīng)會(huì)話層嵌溢， SSL記錄協(xié)議對(duì)應(yīng)表示層，但是這又與SSL握手協(xié)議在SSL記錄協(xié)議之上相違背蹋岩。
那么我們就可以得出結(jié)論：OSI七層模型并不適用于SSL/TLS協(xié)議赖草，這個(gè)人為設(shè)計(jì)的理論參考模型并不能完美地套用在每一個(gè)網(wǎng)絡(luò)協(xié)議上，可能這也是OSI模型被棄用的原因之一吧剪个。
那么對(duì)應(yīng)五層的網(wǎng)絡(luò)模型呢秧骑？由于OSI模型中的L5、L6、L7都合并成了應(yīng)用層乎折，所以SSL/TLS應(yīng)該是屬于傳輸層和應(yīng)用層了绒疗。
3、對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密
講到加密骂澄，必然需要理解加密算法吓蘑，而加密算法一般來(lái)說(shuō)可以分為對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密兩種。
這里的對(duì)稱(chēng)和非對(duì)稱(chēng)是針對(duì)加密和解密這兩個(gè)操作而言的坟冲，一般來(lái)說(shuō)是消息發(fā)送方發(fā)送消息時(shí)需要加密磨镶，消息接收方在接收消息后需要進(jìn)行解密。如果加密和解密用的密鑰是相同的樱衷，則是對(duì)稱(chēng)加密棋嘲；如果不同則是非對(duì)稱(chēng)加密。
3.1 對(duì)稱(chēng)加密
對(duì)稱(chēng)加密算法的特點(diǎn)是算法公開(kāi)矩桂、計(jì)算量小沸移、加密速度快、加密效率高侄榴。常見(jiàn)的對(duì)稱(chēng)加密算法有AES雹锣、DES等。
對(duì)稱(chēng)加密最大的問(wèn)題在于密鑰的傳輸：因?yàn)槿绻畔⒌陌l(fā)送方和接收方是通過(guò)網(wǎng)絡(luò)來(lái)進(jìn)行通信的癞蚕，而在網(wǎng)絡(luò)中使用明文通信是不安全的蕊爵，想要安全通信必須使用密鑰加密，同時(shí)要保證密鑰只有通信雙方知道桦山，但是在傳輸密鑰之前雙方并沒(méi)有一個(gè)安全可靠雙方都知道的密鑰攒射。如果最開(kāi)始的密鑰傳輸過(guò)程使用明文，就可能會(huì)被別有用心的人截獲密鑰恒水，之后的加密就毫無(wú)意義会放。最保險(xiǎn)的方法就是線下傳輸密鑰然后再線上通信，可以參考諜戰(zhàn)片中的特務(wù)舍生取義護(hù)送密碼本钉凌，但是這在互聯(lián)網(wǎng)時(shí)代顯然不靠譜咧最。
3.2 非對(duì)稱(chēng)加密
這時(shí)候非對(duì)稱(chēng)加密就出現(xiàn)了，非對(duì)稱(chēng)加密最大的特點(diǎn)就是把密鑰進(jìn)行分離御雕，將其分成公鑰和私鑰兩個(gè)部分矢沿，常見(jiàn)的非對(duì)稱(chēng)加密算法主要有 RSA 、 DSA 酸纲、ECC等捣鲸。
顧名思義，公鑰是可以用在互聯(lián)網(wǎng)中隨意傳播的闽坡，而私鑰則是需要自己小心保存避免泄露的摄狱。消息的發(fā)送方只需要知道消息接受方的公鑰脓诡，即可將明文通過(guò)公鑰加密然后通過(guò)網(wǎng)絡(luò)傳輸給消息接收方。消息接收方收到密文后媒役，通過(guò)非對(duì)稱(chēng)加密算法，使用自己的私鑰進(jìn)行解密宪迟，即可獲取消息內(nèi)容酣衷。
這里面有幾個(gè)點(diǎn)需要額外關(guān)注一下：
- 公鑰是所有人都可以獲取的，因此想要給接收方發(fā)送消息只需要獲取公鑰即可次泽，所以公鑰可以用明文直接傳輸穿仪，因?yàn)榧词故窃趥鬏斶^(guò)程中泄露了公鑰，由于解密只能使用私鑰意荤，因此整個(gè)數(shù)據(jù)傳輸也還是安全的
- 在通信過(guò)程中一般兩邊都涉及到消息的發(fā)送和接收啊片，因此在通信過(guò)程中一般會(huì)有兩套密鑰對(duì)
- 可以根據(jù)私鑰生成公鑰，反之不行
- 消息發(fā)送方是無(wú)法對(duì)發(fā)送出去的密文解密的玖像，它只能讀取自己保存的明文來(lái)了解之前發(fā)送過(guò)的消息
3.3 數(shù)字證書(shū)
在通信的過(guò)程中紫谷，我們使用公鑰加密，私鑰解密捐寥，因?yàn)樗借€是自己才有的笤昨，而傳輸?shù)男畔⑹遣话踩目赡鼙粍e人截獲的，但是只要對(duì)其進(jìn)行加密握恳，然后保證自己才能解密瞒窒，就可以認(rèn)為傳輸信息是安全的。這就好比使用了一個(gè)很安全的保險(xiǎn)箱來(lái)存放重要資料再快遞到別的地方去乡洼，只要保證只有自己能夠解鎖保險(xiǎn)箱崇裁，那么運(yùn)輸過(guò)程中保險(xiǎn)箱會(huì)被誰(shuí)接觸到都不重要，只要保險(xiǎn)箱送到目的地就可以了束昵。
即便是非對(duì)稱(chēng)加密拔稳，也存在一個(gè)公鑰傳輸?shù)膯?wèn)題∑拊酰基本上存在著兩種方案壳炎，一種是直接把公鑰放到網(wǎng)上，然后讓需要使用的用戶去下載逼侦，另一種就是在通信傳輸過(guò)程中匿辩，由服務(wù)器直接發(fā)送給客戶端。這兩種方法都存在一個(gè)問(wèn)題就是無(wú)法保證公鑰傳輸?shù)陌踩蚤欢m然公鑰是可以給任何人知道的铲球，但是在通信過(guò)程中使用的公鑰必須是通信雙方的公鑰，否則如果出現(xiàn)中間人劫持了通信并且將公鑰替換為中間人自己的公鑰晰赞，那么中間人就可以獲取到通信內(nèi)容稼病。
這個(gè)時(shí)候就需要數(shù)字證書(shū)了选侨，基于非對(duì)稱(chēng)加密公私鑰分離的特性，我們就可以對(duì)公鑰進(jìn)行單獨(dú)操作然走，用于數(shù)字證書(shū)援制，也叫數(shù)字認(rèn)證（digital certificate），即相當(dāng)于現(xiàn)實(shí)生活中的簽名芍瑞，用于證實(shí)身份晨仑。
數(shù)字證書(shū)是部署HTTPS認(rèn)證的網(wǎng)站的必需品，我們?cè)谠L問(wèn)一個(gè)網(wǎng)站的時(shí)候拆檬，一般點(diǎn)擊瀏覽器地址欄旁邊的小鎖就可以看到這時(shí)候正在使用的數(shù)字證書(shū)：
點(diǎn)擊進(jìn)去就可以看到相關(guān)的證書(shū)信息洪己。證書(shū)中包含著十分多的信息，首先最重要的當(dāng)然是對(duì)應(yīng)的域名和公鑰竟贯，其他的還有證書(shū)的生效時(shí)間答捕，使用的加密算法、簽名算法等各種相關(guān)信息屑那。
簽發(fā)證書(shū)的機(jī)構(gòu)被稱(chēng)為 CA（ Certificate Authority）拱镐，理論上每個(gè)人都可以成為CA，因?yàn)槊總€(gè)人都可以自己簽發(fā)證書(shū)齐莲，但是只有極少數(shù)的權(quán)威CA頒發(fā)的證書(shū)才會(huì)被承認(rèn)痢站，這幾大權(quán)威CA的稱(chēng)為ROOT CA，他們的證書(shū)一般都會(huì)內(nèi)置在操作系統(tǒng)中选酗，瀏覽器默認(rèn)是信任這些ROOT CA的證書(shū)的阵难，而這些ROOT CA下屬還有其他的CA，這些下屬的CA可以為各種網(wǎng)站頒發(fā)證書(shū)芒填，根據(jù)層層信任的原則呜叫，瀏覽器也會(huì)信任這些CA下發(fā)的證書(shū)，最終就保證了通信中公鑰傳輸?shù)陌踩?/p>
早期的證書(shū)是需要收費(fèi)的殿衰，但是到了近幾年加密通信的需求增加朱庆，很多網(wǎng)站的運(yùn)營(yíng)者并沒(méi)有那么多錢(qián)來(lái)購(gòu)買(mǎi)證書(shū)（證書(shū)過(guò)期了續(xù)費(fèi)也是要錢(qián)的），這時(shí)候就出現(xiàn)了以Encryption Everywhere闷祥、 Let’s Encrypt等為首的CA開(kāi)始大量普及免費(fèi)的數(shù)字證書(shū)萍桌，如今國(guó)內(nèi)的很多云廠商也提供了各種免費(fèi)的數(shù)字證書(shū)砸泛，從而很好的推動(dòng)了加密通信的發(fā)展龙考。不過(guò)這些免費(fèi)的數(shù)字證書(shū)在安全性上并沒(méi)有企業(yè)級(jí)的收費(fèi)證書(shū)那么高筋现，大多數(shù)都只是DV證書(shū)，如果對(duì)安全性有很高的追求悟衩，還是建議購(gòu)買(mǎi)收費(fèi)的證書(shū)剧罩。
一般來(lái)說(shuō)數(shù)字證書(shū)可以按照安全程度分為以下三類(lèi)：
- EV：EV證書(shū)(Extended Validation Certificate)是一種根據(jù)一系列特定標(biāo)準(zhǔn)頒發(fā)的X.509電子證書(shū)，根據(jù)要求座泳，在頒發(fā)證書(shū)之前惠昔，證書(shū)頒發(fā)機(jī)構(gòu)(CA)必須驗(yàn)證申請(qǐng)者的身份幕与。不同機(jī)構(gòu)根據(jù)證書(shū)標(biāo)準(zhǔn)發(fā)行的擴(kuò)展驗(yàn)證證書(shū)并無(wú)太大差異，但是有時(shí)候根據(jù)一些具體的要求镇防，特定機(jī)構(gòu)發(fā)行的證書(shū)可以被特定的軟件識(shí)別
- OV：OV證書(shū)(Organization Validation SSL)啦鸣，指需要驗(yàn)證網(wǎng)站所有單位的真實(shí)身份的標(biāo)準(zhǔn)型SSL證書(shū)，此類(lèi)證書(shū)不僅能夠起到網(wǎng)站信息加密的作用来氧，而且能向用戶證明網(wǎng)站的真實(shí)身份
- DV：DV證書(shū)(Domain Validation SSL)赏陵，指需要驗(yàn)證域名的有效性。該類(lèi)證書(shū)只提供基本的加密保障饲漾，不能提供域名所有者的信息
4、TLS加密的握手過(guò)程
TLS本身是一個(gè)混合加密系統(tǒng)缕溉，也就是說(shuō)它使用了對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密兩種方式考传，首先是使用非對(duì)稱(chēng)加密來(lái)傳輸在這次會(huì)話過(guò)程中生成的用于生成對(duì)稱(chēng)加密的密鑰（ pre-master key），結(jié)合明文傳輸?shù)碾S機(jī)數(shù)和算法生成堆成加密的密鑰之后再使用對(duì)稱(chēng)加密進(jìn)行通信证鸥。這樣通信的原因是因?yàn)榉菍?duì)稱(chēng)加密雖然很安全僚楞，但是效率實(shí)在是太低了（比對(duì)稱(chēng)加密慢幾個(gè)數(shù)量級(jí)），因此只用來(lái)傳輸對(duì)稱(chēng)加密的密鑰枉层，之后就使用效率更高的對(duì)稱(chēng)加密來(lái)通信泉褐。
TLS支持多種密鑰交換算法（key exchange algorithms） 和加密算法（ciphersuites），不同的客戶端和服務(wù)器之間支持的也各不相同鸟蜡，因此在加密通信之間就需要進(jìn)行協(xié)商膜赃，客戶端和服務(wù)端需要協(xié)商清楚使用何種算法，使用何種加密方式揉忘，使用什么密鑰等等問(wèn)題跳座，這一個(gè)過(guò)程稱(chēng)為握手過(guò)程（handshake）。就好像TCP連接在建立前需要進(jìn)行三次握手一樣泣矛，所有的TLS通信在開(kāi)始之前都需要進(jìn)行握手（handshake）疲眷。當(dāng)客戶端和服務(wù)器完成TCP三次握手建立TCP連接之后，就開(kāi)始進(jìn)行TLS的握手過(guò)程您朽，具體的流程如下：
- 首先由客戶端發(fā)送Client Hello 消息到服務(wù)器狂丝，消息中主要包含了客戶端支持的
ciphersuites， TLS 版本信息和客戶端隨機(jī)數(shù)哗总。注意此時(shí)是明文傳輸 - 服務(wù)器接收到消息后几颜，返回自己支持的
ciphersuites， TLS 版本魂奥，自己的數(shù)字證書(shū)和服務(wù)器端生成的隨機(jī)數(shù)菠剩。注意此時(shí)是明文傳輸 - 客戶端開(kāi)始驗(yàn)證數(shù)字證書(shū)，可能會(huì)不斷往上追溯 CA耻煤、CA 的 CA具壮、CA 的 CA 的 CA准颓，直到一個(gè)授信的 CA。驗(yàn)證完證書(shū)之后生成一個(gè)新的
pre-master key棺妓，再使用證書(shū)中的公鑰來(lái)對(duì)pre-master key進(jìn)行加密攘已，然后發(fā)送給服務(wù)器。注意此時(shí)是非對(duì)稱(chēng)加密傳輸 - 服務(wù)器接收到客戶端發(fā)送過(guò)來(lái)的非對(duì)稱(chēng)加密的密文怜跑，使用自己的私鑰進(jìn)行解密样勃，獲得了
pre-master key。注意此時(shí)是非對(duì)稱(chēng)加密傳輸 - 到這里為止性芬，服務(wù)器和客戶端都有三組數(shù)字峡眶，分別是客戶端的隨機(jī)數(shù)、服務(wù)器的隨機(jī)數(shù)和pre-master key植锉。其中由于客戶端的隨機(jī)數(shù)和服務(wù)器的隨機(jī)數(shù)都是使用明文傳輸辫樱，所以這兩個(gè)數(shù)字是有被暴露的風(fēng)險(xiǎn)的，但是由于
pre-master key是使用非對(duì)稱(chēng)加密傳輸俊庇，十分安全狮暑，所以將這三者結(jié)合，使用之前協(xié)商好的特定的算法就可以生成一個(gè)密鑰辉饱，這個(gè)密鑰稱(chēng)為shared secert搬男。也就是之后用來(lái)對(duì)稱(chēng)加密的密鑰。 - 客戶端在計(jì)算出對(duì)稱(chēng)加密的密鑰之后彭沼，使用該密鑰進(jìn)行對(duì)稱(chēng)加密通信缔逛，告知服務(wù)器之后都使用該密鑰進(jìn)行對(duì)稱(chēng)加密。注意此時(shí)是對(duì)稱(chēng)加密傳輸
- 服務(wù)器接收到密文后溜腐，使用之前計(jì)算出的密鑰來(lái)進(jìn)行對(duì)稱(chēng)解密译株，解密成功之后，再使用該密鑰進(jìn)行對(duì)稱(chēng)加密通信挺益。告知客戶端密鑰確認(rèn)無(wú)誤歉糜，可以使用該密鑰進(jìn)行通信。注意此時(shí)是對(duì)稱(chēng)加密傳輸
- 至此望众，整個(gè)TLS的握手過(guò)程完整匪补，之后就可以開(kāi)始對(duì)稱(chēng)加密的通信了。
全過(guò)程如下圖所示：
在RFC5246文檔中我們也可以看到對(duì)應(yīng)的簡(jiǎn)單圖示
整體流程和上面的基本相同烂翰，都是需要進(jìn)行兩個(gè)RTT操作夯缺。
5、TLS1.2的問(wèn)題
縱觀整個(gè)SSL/TLS協(xié)議的發(fā)展史甘耿，我們可以發(fā)現(xiàn)整個(gè)SSL/TLS協(xié)議就是不斷地填坑的一個(gè)過(guò)程踊兜，不斷地對(duì)舊版本的協(xié)議中的各種漏洞進(jìn)行修補(bǔ)迭代更新，然后發(fā)布新的版本佳恬，直到TLSv1.2版本才算是一個(gè)不錯(cuò)的可用的加密協(xié)議版本捏境。即便如此于游，對(duì)應(yīng)TLSv1.2來(lái)說(shuō)還是有著太多的歷史包袱和兼容性的問(wèn)題，盡管在功能實(shí)現(xiàn)上的漏洞可以通過(guò)補(bǔ)丁來(lái)進(jìn)行修補(bǔ)垫言，但是在協(xié)議設(shè)計(jì)之初就存在的問(wèn)題是沒(méi)有辦法修復(fù)的贰剥，只能推倒重來(lái)，于是就出現(xiàn)了后面的TLSv1.3筷频。這里我們先了解一下TLSv1.2版本中的一些主要的問(wèn)題：
5.1 安全問(wèn)題
作為一個(gè)提供安全通信的協(xié)議蚌成，安全問(wèn)題是首要的也是致命的問(wèn)題。TLS發(fā)展到1.2以來(lái)凛捏，已經(jīng)被很多機(jī)構(gòu)和學(xué)者曝出有各種各樣的安全漏洞担忧，包括密鑰交換算法（key exchange algorithms）、加密套件（ciphersuites）和數(shù)字簽名（digital signatures）各個(gè)方面都存在安全問(wèn)題坯癣，很多都是由于歷史原因兼容問(wèn)題而遺留下來(lái)的問(wèn)題涵妥。
還有一些則是設(shè)計(jì)協(xié)議本身就存在的問(wèn)題如TLS重新協(xié)議（renegotiation）可以讓心懷不軌的人將高版本的TLS協(xié)議重新協(xié)商降級(jí)到低版本的不安全的協(xié)議然后進(jìn)行攻擊。又或者是SNI的不加密問(wèn)題坡锡，TLS1.2及之前的協(xié)議都不對(duì)SNI進(jìn)行加密，這也存在了很大的風(fēng)險(xiǎn)窒所。
5.2 性能問(wèn)題
互聯(lián)網(wǎng)上一直存在著加密傳輸對(duì)性能有很大損耗的說(shuō)法鹉勒，實(shí)際上了解了上面的TLSv1.2握手過(guò)程之后，我們可以知道加密傳輸對(duì)性能確實(shí)有損耗吵取，但是遠(yuǎn)沒(méi)有到很多人鼓吹的那么嚴(yán)重的程度禽额。而且在后面也加入了很多諸如OCSP、HSTS等技術(shù)來(lái)提高其性能表現(xiàn)皮官，但是即便如此脯倒，整個(gè)TLSv1.2的握手過(guò)程也需要2-RTT，也就是在客戶端和服務(wù)器之間來(lái)回兩次才能順利建立TLS傳輸捺氢，這還是在一切都進(jìn)行順利的情況下藻丢。
6、TLS1.3的改進(jìn)
TLSv1.3是TLS協(xié)議更新中變化非常大的一個(gè)版本摄乒，加入了許多新的特性和性能優(yōu)化悠反，并且不完全前向兼容，因此也有些人認(rèn)為應(yīng)該稱(chēng)為T(mén)LSv2.0馍佑，不過(guò)最后還是命名為T(mén)LSv1.3斋否。
針對(duì)TLSv1.2中存在的安全和性能問(wèn)題，TLSv1.3在設(shè)計(jì)的時(shí)候就放棄了前向兼容性拭荤，不再對(duì)之前的版本進(jìn)行兼容茵臭，同時(shí)禁用了大量不安全的算法，使用了少量安全的算法來(lái)設(shè)計(jì)協(xié)議舅世，這樣的好處就是可以簡(jiǎn)化握手過(guò)程中的操作旦委，使得握手過(guò)程從2-RTT變?yōu)?-RTT奇徒，同時(shí)有效提高安全性和性能。
6.1 TLS1.3和TLS1.2的主要不同
- 部分新的密碼套件（ciphersuite）只能在TLSv1.3中工作社证，并且TLSv1.3不支持之前在TLSv1.2前用的舊的密碼套件
ciphersuites逼龟。也就是說(shuō)如果需要使用TLSv1.3就必須要添加新的只能在TLSv1.3中使用的密碼套件 - 新的密碼套件（
ciphersuites）和之前的密碼套件定義不同，并不需要指定對(duì)應(yīng)的證書(shū)類(lèi)型(e.g. RSA, DSA, ECDSA) 或者是密鑰交換機(jī)制 (e.g. DHE or ECHDE) - TLSv1.3不再支持DSA證書(shū)
- TLS1.3中不再支持重新協(xié)商（Renegotiation）追葡，即不可能像TLSv1.2之前那樣通過(guò)重新協(xié)商來(lái)回退到更早的更不安全的版本
- TLS1.3中更多的握手過(guò)程都被加密了（Server Hello之后都會(huì)進(jìn)行加密）
- TLSv1.3支持更多的的消息類(lèi)型腺律，即對(duì)自定義的擴(kuò)展API和認(rèn)證傳輸有更好的擴(kuò)展性
- 客戶端在TLS握手階段發(fā)送ClientHello數(shù)據(jù)包的時(shí)候需要提供支持的密碼套件（ciphersuite）和密鑰共享（key_share）從而提高速度，如果client發(fā)送的
keyshare類(lèi)型是server不支持宜肉，那就不是1-RTT匀钧。 - sessions會(huì)話在TLS握手完成之后才會(huì)建立，所以在session和TLS握手之間可能會(huì)有空隙（即不是連續(xù)的）
6.2 TLS1.3中的密鑰交換算法
TLS 1.3的核心宗旨是簡(jiǎn)單性谬返。在新版本中之斯，除去了Diffie-Hellman（DH）密鑰交換以外的所有密鑰交換算法。TLS 1.3還定義了一組經(jīng)過(guò)測(cè)試的DH參數(shù)遣铝，無(wú)需與服務(wù)器協(xié)商參數(shù)佑刷。由于只有一個(gè)密鑰交換算法（具有內(nèi)置參數(shù)）和少數(shù)支持的密碼，因此設(shè)置TLS 1.3通道所需的絕對(duì)帶寬比早期版本要少得多酿炸。
我們來(lái)看DH算法交換密鑰的步驟瘫絮。假設(shè)客戶端和服務(wù)器雙方需要傳遞密鑰，他們之間可以這么做：
- 客戶端首選選擇一個(gè)素?cái)?shù)
p填硕，例如509麦萤，底數(shù)g，任選扁眯，例如5壮莹，隨機(jī)數(shù)a，例如123姻檀，然后計(jì)算A=g^a mod p命满，結(jié)果是215，然后绣版，客戶端發(fā)送p＝509周荐，g=5，A=215給服務(wù)器僵娃； - 服務(wù)器收到后概作，也選擇一個(gè)隨機(jī)數(shù)
b，例如默怨，456讯榕，然后計(jì)算B=g^b mod p，結(jié)果是181，服務(wù)器再同時(shí)計(jì)算s=A^b mod p愚屁，結(jié)果是121济竹； - 服務(wù)器把計(jì)算的
B=181發(fā)給客戶端，客戶端計(jì)算s＝B^a mod p的余數(shù)霎槐，計(jì)算結(jié)果與服務(wù)器算出的結(jié)果一樣送浊，都是121。
所以最終雙方協(xié)商出的密鑰s是121丘跌。注意到這個(gè)密鑰s并沒(méi)有在網(wǎng)絡(luò)上傳輸袭景。而通過(guò)網(wǎng)絡(luò)傳輸?shù)?code>p，g闭树，A和B是無(wú)法推算出s的耸棒，因?yàn)閷?shí)際算法選擇的素?cái)?shù)是非常大的。所以报辱，更確切地說(shuō)与殃，DH算法是一個(gè)密鑰協(xié)商算法碍现，雙方最終協(xié)商出一個(gè)共同的密鑰，而這個(gè)密鑰不會(huì)通過(guò)網(wǎng)絡(luò)傳輸昼接。
6.3 TLS1.3握手過(guò)程
整個(gè)流程的目的和TLS 1.2是相似的，TLS握手過(guò)程就是為了讓雙方能夠得到一個(gè)安全的可用于對(duì)稱(chēng)加密的密鑰辩棒。和之前不一樣的就是膨疏，無(wú)非就是客戶端提前把所有的公鑰計(jì)算了一遍，發(fā)給server佃却，server再挑選者吁。
7、wireshark抓包
使用wireshark對(duì)TLSv1.3握手過(guò)程進(jìn)行抓包复凳，未解密的情況如下圖灶泵。我們可以看到在Server Hello階段之后的數(shù)據(jù)就已經(jīng)被加密了赦邻，無(wú)法查看具體的數(shù)據(jù)情況，均顯示為Application Data
對(duì)其進(jìn)行解密操作之后就可以看到其中的數(shù)據(jù)情況按声，其中的Encrypted Extensions就是對(duì)SNI部分進(jìn)行了加密。
解密前的TLSv1.2握手過(guò)程须床，可以看到直到Change Cipher Spec階段都是沒(méi)有進(jìn)行加密的渐裂。
解密后的TLSv1.2握手過(guò)程芯义，我們可以看到被加密的部分也就是Encrypted Handshake Message實(shí)際上就是Finished消息，用于檢驗(yàn)對(duì)稱(chēng)加密的密鑰是可以正常工作的耘分。
