專題一戒祠，主要介紹HTTPS建立安全鏈接的原理，包括非對(duì)稱加密撩轰、對(duì)稱加密档桃、CA認(rèn)證等知識(shí)，還包括對(duì)一些業(yè)界常用算法的優(yōu)缺點(diǎn)對(duì)比蝶防，性能簡介與對(duì)比等甚侣。

專題二，主要采用實(shí)地抓包方式间学，看看HTTPS建立鏈接的整個(gè)過程殷费，并結(jié)合專題一的原理知識(shí)加以講解印荔，可以更直觀地理解建立HTTPS連接的整個(gè)過程。

專題二未列出請(qǐng)參考知乎鏈接：https://zhuanlan.zhihu.com/p/22142170

專題一：HTTPS為什么安全

1详羡、http為什么不安全仍律？

http協(xié)議屬于明文傳輸協(xié)議，交互過程以及數(shù)據(jù)傳輸都沒有進(jìn)行加密实柠，通信雙方也沒有進(jìn)行任何認(rèn)證水泉，通信過程非常容易遭遇劫持、監(jiān)聽窒盐、篡改草则，嚴(yán)重情況下，會(huì)造成惡意的流量劫持等問題登钥，甚至造成個(gè)人隱私泄露（比如銀行卡卡號(hào)和密碼泄露）等嚴(yán)重的安全問題畔师。

可以把http通信比喻成寄送信件一樣，A給B寄信牧牢，信件在寄送過程中看锉，會(huì)經(jīng)過很多的郵遞員之手，他們可以拆開信讀取里面的內(nèi)容（因?yàn)閔ttp是明文傳輸?shù)模┧ⅰ的信件里面的任何內(nèi)容（包括各類賬號(hào)和密碼）都會(huì)被輕易竊取伯铣。除此之外，郵遞員們還可以偽造或者修改信件的內(nèi)容轮纫，導(dǎo)致B接收到的信件內(nèi)容是假的腔寡。

比如常見的，在http通信過程中掌唾，“中間人”將廣告鏈接嵌入到服務(wù)器發(fā)給用戶的http報(bào)文里放前，導(dǎo)致用戶界面出現(xiàn)很多不良鏈接；或者是修改用戶的請(qǐng)求頭URL糯彬，導(dǎo)致用戶的請(qǐng)求被劫持到另外一個(gè)網(wǎng)站凭语，用戶的請(qǐng)求永遠(yuǎn)到不了真正的服務(wù)器。這些都會(huì)導(dǎo)致用戶得不到正確的服務(wù)撩扒，甚至是損失慘重似扔。

2、https如何保證安全搓谆？

要解決http帶來的問題炒辉，就要引入加密以及身份驗(yàn)證機(jī)制。

如果Server（以后簡稱服務(wù)器）給Client（以后簡稱客戶端）的消息是密文的泉手，只有服務(wù)器和客戶端才能讀懂黔寇，就可以保證數(shù)據(jù)的保密性。同時(shí)斩萌，在交換數(shù)據(jù)之前缝裤，驗(yàn)證一下對(duì)方的合法身份状囱，就可以保證通信雙方的安全。那么倘是，問題來了，服務(wù)器把數(shù)據(jù)加密后袭艺，客戶端如何讀懂這些數(shù)據(jù)呢搀崭？這時(shí)服務(wù)器必須要把加密的密鑰（對(duì)稱密鑰，后面會(huì)詳細(xì)說明）告訴客戶端猾编，客戶端才能利用對(duì)稱密鑰解開密文的內(nèi)容瘤睹。但是，服務(wù)器如果將這個(gè)對(duì)稱密鑰以明文的方式給客戶端答倡，還是會(huì)被中間人截獲轰传，中間人也會(huì)知道對(duì)稱密鑰，依然無法保證通信的保密性瘪撇。但是获茬，如果服務(wù)器以密文的方式將對(duì)稱密鑰發(fā)給客戶端，客戶端又如何解開這個(gè)密文倔既，得到其中的對(duì)稱密鑰呢恕曲？

說到這里，大家是不是有點(diǎn)兒糊涂了渤涌？一會(huì)兒密鑰佩谣，一會(huì)兒對(duì)稱密鑰，都有點(diǎn)兒被搞暈的節(jié)奏实蓬。在這里茸俭，提前給大家普及一下，這里的密鑰安皱，指的是非對(duì)稱加解密的密鑰调鬓，是用于TLS握手階段的；對(duì)稱密鑰练俐，指的是對(duì)稱加解密的密鑰袖迎，是用于后續(xù)傳輸數(shù)據(jù)加解密的。下面將詳細(xì)說明腺晾。

這時(shí)燕锥，我們引入了非對(duì)稱加解密的概念。在非對(duì)稱加解密算法里悯蝉，公鑰加密的數(shù)據(jù)归形，有且只有唯一的私鑰才能夠解密，所以服務(wù)器只要把公鑰發(fā)給客戶端鼻由，客戶端就可以用這個(gè)公鑰來加密進(jìn)行數(shù)據(jù)傳輸?shù)膶?duì)稱密鑰暇榴『窨茫客戶端利用公鑰將對(duì)稱密鑰發(fā)給服務(wù)器時(shí)，即使中間人截取了信息蔼紧，也無法解密婆硬，因?yàn)樗借€只部署在服務(wù)器，其他任何人都沒有私鑰奸例，因此彬犯，只有服務(wù)器才能夠解密。服務(wù)器拿到客戶端的信息并用私鑰解密之后查吊，就可以拿到加解密數(shù)據(jù)用的對(duì)稱密鑰谐区，通過這個(gè)對(duì)稱密鑰來進(jìn)行后續(xù)通信的數(shù)據(jù)加解密。除此之外逻卖，非對(duì)稱加密可以很好的管理對(duì)稱密鑰宋列，保證每次數(shù)據(jù)加密的對(duì)稱密鑰都是不相同的，這樣子的話评也，即使客戶端病毒拉取到通信緩存信息炼杖，也無法竊取正常通信內(nèi)容。

上述通信過程仇参，可以畫成以下交互圖：

[圖片上傳失敗...(image-a04ad0-1534685167796)]

但是這樣似乎還不夠嘹叫，如果通信過程中，在三次握手或者客戶端發(fā)起HTTP請(qǐng)求過程中诈乒，客戶端的請(qǐng)求被中間人劫持罩扇，那么中間人就可以偽裝成“假冒客戶端”和服務(wù)器通信；中間人又可以偽裝成“假冒服務(wù)器”和客戶端通信怕磨。接下來喂饥，我們詳細(xì)闡述中間人獲取對(duì)稱密鑰的過程：

中間人在收到服務(wù)器發(fā)送給客戶端的公鑰（這里是“正確的公鑰”）后，并沒有發(fā)給客戶端肠鲫，而是中間人將自己的公鑰（這里中間人也會(huì)有一對(duì)公鑰和私鑰员帮，這里稱呼為“偽造公鑰”）發(fā)給客戶端。之后导饲，客戶端把對(duì)稱密鑰用這個(gè)“偽造公鑰”加密后捞高，發(fā)送過程中經(jīng)過了中間人，中間人就可以用自己的私鑰解密數(shù)據(jù)并拿到對(duì)稱密鑰渣锦，此時(shí)中間人再把對(duì)稱密鑰用“正確的公鑰”加密發(fā)回給服務(wù)器硝岗。此時(shí)，客戶端袋毙、中間人型檀、服務(wù)器都擁有了一樣的對(duì)稱密鑰，后續(xù)客戶端和服務(wù)器的所有加密數(shù)據(jù)听盖，中間人都可以通過對(duì)稱密鑰解密出來胀溺。

中間人獲取對(duì)稱密鑰的過程如下：

[圖片上傳失敗...(image-ac7547-1534685167796)]

為了解決此問題裂七，我們引入了數(shù)字證書的概念。服務(wù)器首先生成公私鑰仓坞，將公鑰提供給相關(guān)機(jī)構(gòu)（CA）背零，CA將公鑰放入數(shù)字證書并將數(shù)字證書頒布給服務(wù)器，此時(shí)服務(wù)器就不是簡單的把公鑰給客戶端无埃，而是給客戶端一個(gè)數(shù)字證書捉兴，數(shù)字證書中加入了一些數(shù)字簽名的機(jī)制，保證了數(shù)字證書一定是服務(wù)器給客戶端的录语。中間人發(fā)送的偽造證書，不能夠獲得CA的認(rèn)證禾乘，此時(shí)澎埠，客戶端和服務(wù)器就知道通信被劫持了。加入了CA數(shù)字簽名認(rèn)證的SSL會(huì)話過程如下所示：

[圖片上傳失敗...(image-48c3b5-1534685167796)]

所以綜合以上三點(diǎn)：非對(duì)稱加密算法（公鑰和私鑰）交換對(duì)稱密鑰+數(shù)字證書驗(yàn)證身份（驗(yàn)證公鑰是否是偽造的）+利用對(duì)稱密鑰加解密后續(xù)傳輸?shù)臄?shù)據(jù)=安全始藕。

[圖片上傳失敗...(image-fcd946-1534685167796)]

3伍派、https協(xié)議簡介

為什么是簡單地介紹https協(xié)議呢诉植？因?yàn)閔ttps涉及的東西實(shí)在太多了，尤其是其中的加解密算法舌稀，十分復(fù)雜，作者本身對(duì)這些算法也研究不完，只是懂其中的一些皮毛而已席怪。這部分僅僅是簡單介紹一些關(guān)于https的最基本原理，為后面分析https的建立過程以及https優(yōu)化等內(nèi)容打下理論基礎(chǔ)惜辑。

3.1 對(duì)稱加密算法

對(duì)稱加密是指：加密和解密使用相同密鑰的算法。它要求發(fā)送方和接收方在安全通信之前抵卫，商定一個(gè)對(duì)稱密鑰晚树。對(duì)稱算法的安全性完全依賴于密鑰慨亲，密鑰泄漏就意味著任何人都可以對(duì)他們發(fā)送或接收的消息解密愚铡，所以密鑰的保密性對(duì)通信至關(guān)重要正蛙。

3.1.1 對(duì)稱加密又分為兩種模式

流加密是將消息作為字節(jié)流對(duì)待蒂阱，并且使用數(shù)學(xué)函數(shù)分別作用在每一個(gè)字節(jié)位上。使用流加密時(shí)，每加密一次萝勤，相同的明文位會(huì)轉(zhuǎn)換成不同的密文位伶氢。流加密使用了密鑰流生成器，它生成的字節(jié)流與明文字節(jié)流進(jìn)行異或，從而生成密文迅腔。

分組加密是將消息劃分為若干個(gè)分組，這些分組隨后會(huì)通過數(shù)學(xué)函數(shù)進(jìn)行處理，每次一個(gè)分組婿牍。假設(shè)使用64位的分組密碼，此時(shí)如果消息長度為640位惩歉，就會(huì)被劃分成10個(gè)64位的分組（如果最后一個(gè)分組長度不到64撑蚌，則用0補(bǔ)齊之后加到64位），每個(gè)分組都用一系列數(shù)學(xué)公式進(jìn)行處理，最后得到10個(gè)加密文本分組特铝。然后，將這條密文消息發(fā)送給對(duì)端灵莲。對(duì)端必須擁有相同的分組密碼雕凹，以相反的順序?qū)?0個(gè)密文分組使用前面的算法解密，最終得到明文消息明场。比較常用的分組加密算法有DES汽摹、3DES、AES苦锨。其中DES是比較老的加密算法逼泣，現(xiàn)在已經(jīng)被證明不安全。而3DES是一個(gè)過渡的加密算法舟舒，相當(dāng)于在DES基礎(chǔ)上進(jìn)行三重運(yùn)算來提高安全性拉庶，但其本質(zhì)上還是和DES算法一致。而AES是DES算法的替代算法秃励，是現(xiàn)在最安全的對(duì)稱加密算法之一氏仗。

3.1.2 對(duì)稱加密算法的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：計(jì)算量小、加密速度快夺鲜、加密效率高廓鞠。

缺點(diǎn)：

（1）交易雙方都使用同樣密鑰，安全性得不到保證谣旁；

（2）每次使用對(duì)稱加密算法時(shí)床佳，都需要使用其他人不知道的惟一密鑰，這會(huì)使得發(fā)收信息雙方所擁有的鑰匙數(shù)量呈幾何級(jí)數(shù)增長榄审，密鑰管理成為負(fù)擔(dān)砌们。

3.2 非對(duì)稱加密算法

在非對(duì)稱密鑰交換算法出現(xiàn)以前，對(duì)稱加密的最主要缺陷就是不知道如何在通信雙方之間傳輸對(duì)稱密鑰，而又不讓中間人竊取浪感。非對(duì)稱密鑰交換算法誕生之后昔头，專門針對(duì)對(duì)稱密鑰傳輸做加解密，使得對(duì)稱密鑰的交互傳輸變得非常安全了影兽。

非對(duì)稱密鑰交換算法本身非常復(fù)雜揭斧，密鑰交換過程涉及到隨機(jī)數(shù)生成，模指數(shù)運(yùn)算峻堰，空白補(bǔ)齊讹开，加密，簽名等等一系列極其復(fù)雜的過程捐名，作者本人也沒有研究完全透徹旦万。常見的密鑰交換算法有RSA，ECDHE镶蹋，DH成艘，DHE等算法。涉及到比較復(fù)雜的數(shù)學(xué)問題贺归。其中淆两，最經(jīng)典也是最常用的是RSA算法。

RSA：誕生于1977年拂酣，經(jīng)過了長時(shí)間的破解測試秋冰，算法安全性很高，最重要的是踱葛，算法實(shí)現(xiàn)非常簡單。缺點(diǎn)就是需要比較大的質(zhì)數(shù)（目前常用的是2048位）來保證安全強(qiáng)度光坝，極其消耗CPU運(yùn)算資源尸诽。RSA是目前唯一一個(gè)既能用于密鑰交換又能用于證書簽名的算法，RSA 是最經(jīng)典盯另，同時(shí)也是最常用的是非對(duì)稱加解密算法性含。

3.2.1 非對(duì)稱加密缺點(diǎn)

（1）CPU計(jì)算資源消耗非常大。一次完全TLS握手鸳惯，密鑰交換時(shí)的非對(duì)稱解密計(jì)算量占整個(gè)握手過程的90%以上商蕴。而對(duì)稱加密的計(jì)算量只相當(dāng)于非對(duì)稱加密的0.1%。如果后續(xù)的應(yīng)用層數(shù)據(jù)傳輸過程也使用非對(duì)稱加解密芝发，那么CPU性能開銷太龐大绪商，服務(wù)器是根本無法承受的。賽門特克給出的實(shí)驗(yàn)數(shù)據(jù)顯示辅鲸，加解密同等數(shù)量的文件格郁，非對(duì)稱算法消耗的CPU資源是對(duì)稱算法的1000倍以上。

（2）非對(duì)稱加密算法對(duì)加密內(nèi)容的長度有限制，不能超過公鑰長度例书。比如現(xiàn)在常用的公鑰長度是2048位锣尉，意味著待加密內(nèi)容不能超過256個(gè)字節(jié)。

所以非對(duì)稱加解密（極端消耗CPU資源）目前只能用來做對(duì)稱密鑰交換或者CA簽名决采，不適合用來做應(yīng)用層內(nèi)容傳輸?shù)募咏饷堋?/p>

3.3 身份認(rèn)證

https協(xié)議中身份認(rèn)證的部分是由CA數(shù)字證書完成的自沧，證書由公鑰、證書主體树瞭、數(shù)字簽名等內(nèi)容組成拇厢。在客戶端發(fā)起SSL請(qǐng)求后，服務(wù)端會(huì)將數(shù)字證書發(fā)給客戶端移迫，客戶端會(huì)對(duì)證書進(jìn)行驗(yàn)證（驗(yàn)證這張證書是否是偽造的旺嬉？也就是公鑰是否是偽造的），如果證書不是偽造的厨埋，客戶端就獲取用于對(duì)稱密鑰交換的非對(duì)稱密鑰（獲取公鑰）邪媳。

3.3.1 數(shù)字證書有三個(gè)作用

1、身份授權(quán)荡陷。確保瀏覽器訪問的網(wǎng)站是經(jīng)過CA驗(yàn)證的可信任的網(wǎng)站雨效。

2、分發(fā)公鑰废赞。每個(gè)數(shù)字證書都包含了注冊者生成的公鑰（驗(yàn)證確保是合法的徽龟，非偽造的公鑰）。在SSL握手時(shí)會(huì)通過certificate消息傳輸給客戶端唉地。

3据悔、驗(yàn)證證書合法性≡耪樱客戶端接收到數(shù)字證書后极颓，會(huì)對(duì)證書合法性進(jìn)行驗(yàn)證。只有驗(yàn)證通過后的證書群嗤，才能夠進(jìn)行后續(xù)通信過程菠隆。

3.3.2 申請(qǐng)受信任的CA數(shù)字證書流程

（1）公司（實(shí)體）的服務(wù)器生成公鑰和私鑰，以及CA數(shù)字證書請(qǐng)求狂秘。

（2）RA（證書注冊及審核機(jī)構(gòu)）檢查實(shí)體的合法性（在注冊系統(tǒng)里面是否注冊過的正規(guī)公司）骇径。

（3）CA（證書簽發(fā)機(jī)構(gòu)）簽發(fā)證書，發(fā)送給申請(qǐng)者實(shí)體者春。

（4）證書更新到repository（負(fù)責(zé)數(shù)字證書及CRL內(nèi)容存儲(chǔ)和分發(fā)）破衔，實(shí)體終端后續(xù)從repository更新證書，查詢證書狀態(tài)等钱烟。

3.4 數(shù)字證書驗(yàn)證

申請(qǐng)者拿到CA的證書并部署在網(wǎng)站服務(wù)器端运敢，那瀏覽器發(fā)起握手并接收到證書后校仑，如何確認(rèn)這個(gè)證書就是CA簽發(fā)的呢？怎樣避免第三方偽造這個(gè)證書传惠？答案就是數(shù)字簽名（digital signature）迄沫。數(shù)字簽名是證書的防偽標(biāo)簽，目前使用最廣泛的SHA-RSA（SHA用于哈希算法卦方，RSA用于非對(duì)稱加密算法）羊瘩。數(shù)字簽名的制作和驗(yàn)證過程如下：

1、數(shù)字簽名的簽發(fā)盼砍。首先是使用哈希函數(shù)對(duì)待簽名內(nèi)容進(jìn)行安全哈希尘吗，生成消息摘要，然后使用CA自己的私鑰對(duì)消息摘要進(jìn)行加密浇坐。

2睬捶、數(shù)字簽名的校驗(yàn)。使用CA的公鑰解密簽名近刘，然后使用相同的簽名函數(shù)對(duì)簽名證書內(nèi)容進(jìn)行簽名擒贸，并和服務(wù)端數(shù)字簽名里的簽名內(nèi)容進(jìn)行比較，如果相同就認(rèn)為校驗(yàn)成功觉渴。

[圖片上傳失敗...(image-586b0f-1534685167796)]

需要注意的是：

（1）數(shù)字簽名簽發(fā)和校驗(yàn)使用的非對(duì)稱密鑰是CA自己的公鑰和私鑰介劫，跟證書申請(qǐng)者（提交證書申請(qǐng)的公司實(shí)體）提交的公鑰沒有任何關(guān)系。

（2）數(shù)字簽名的簽發(fā)過程跟公鑰加密的過程剛好相反案淋，即是用私鑰加密座韵，公鑰解密。（一對(duì)公鑰和私鑰踢京，公鑰加密的內(nèi)容只有私鑰能夠解密誉碴；反過來，私鑰加密的內(nèi)容瓣距，也就有公鑰才能夠解密）

（3）現(xiàn)在大的CA都會(huì)有證書鏈黔帕，證書鏈的好處：首先是安全，保持CA的私鑰離線使用旨涝。第二個(gè)好處是方便部署和撤銷蹬屹。這里為啥要撤銷呢侣背？因?yàn)榘谆绻鸆A數(shù)字證書出現(xiàn)問題（被篡改或者污染），只需要撤銷相應(yīng)級(jí)別的證書贩耐，根證書依然是安全的弧腥。

（4）根CA證書都是自簽名，即用自己的公鑰和私鑰完成了簽名的制作和驗(yàn)證潮太。而證書鏈上的證書簽名都是使用上一級(jí)證書的非對(duì)稱密鑰進(jìn)行簽名和驗(yàn)證的管搪。

（5）怎樣獲取根CA和多級(jí)CA的密鑰對(duì)虾攻？還有，既然是自簽名和自認(rèn)證更鲁，那么它們是否安全可信霎箍？這里的答案是：當(dāng)然可信，因?yàn)檫@些廠商跟瀏覽器和操作系統(tǒng)都有合作澡为，它們的根公鑰都默認(rèn)裝到了瀏覽器或者操作系統(tǒng)環(huán)境里漂坏。

3.5 數(shù)據(jù)完整性驗(yàn)證

數(shù)據(jù)傳輸過程中的完整性使用MAC算法來保證。為了避免網(wǎng)絡(luò)中傳輸?shù)臄?shù)據(jù)被非法篡改媒至，或者數(shù)據(jù)比特被污染顶别，SSL利用基于MD5或SHA的MAC算法來保證消息的完整性（由于MD5在實(shí)際應(yīng)用中存在沖突的可能性比較大，所以盡量別采用MD5來驗(yàn)證內(nèi)容一致性）拒啰。 MAC算法是在密鑰參與下的數(shù)據(jù)摘要算法驯绎，能將密鑰和任意長度的數(shù)據(jù)轉(zhuǎn)換為固定長度的數(shù)據(jù)。發(fā)送者在密鑰的作用下谋旦，利用MAC算法計(jì)算出消息的MAC值剩失，并將其添加在需要發(fā)送的消息之后，并發(fā)送給接收者蛤织。接收者利用同樣的密鑰和MAC算法計(jì)算出消息的MAC值赴叹，并與接收到的MAC值比較。如果二者相同指蚜，則報(bào)文沒有改變乞巧；否則，報(bào)文在傳輸過程中被修改或者污染摊鸡，接收者將丟棄該報(bào)文绽媒。 SHA也不能使用SHA0和SHA1，山東大學(xué)的王小云教授（很牛的一個(gè)女教授免猾，大家有興趣可以上網(wǎng)搜索一下她的事跡）在2005年就宣布破解了 SHA-1完整版算法是辕，并獲得了業(yè)內(nèi)專家的認(rèn)可。微軟和google都已經(jīng)宣布16年及17年之后不再支持sha1簽名證書猎提。

總結(jié)

1获三、對(duì)稱加密

有流式、分組兩種锨苏，加密和解密都是使用的同一個(gè)密鑰疙教。

例如：DES、AES-GCM伞租、ChaCha20-Poly1305等

2贞谓、非對(duì)稱加密

加密使用的密鑰和解密使用的密鑰是不相同的，分別稱為：公鑰葵诈、私鑰裸弦，公鑰和算法都是公開的祟同，私鑰是保密的。非對(duì)稱加密算法性能較低理疙，但是安全性超強(qiáng)晕城，由于其加密特性，非對(duì)稱加密算法能加密的數(shù)據(jù)長度也是有限的窖贤。

例如：RSA广辰、DSA、ECDSA主之、DH择吊、ECDHE

3、哈希算法

將任意長度的信息轉(zhuǎn)換為較短的固定長度的值槽奕，通常其長度要比信息小得多几睛，且算法不可逆– 摘要。

例如：MD5粤攒、SHA-1所森、SHA-2、SHA-256 等

4夯接、數(shù)字簽名

簽名就是在信息的后面再加上一段內(nèi)容（信息經(jīng)過hash后的值）焕济，可以證明信息沒有被修改過。hash值一般都會(huì)加密后（也就是簽名）再和信息一起發(fā)送盔几，以保證這個(gè)hash值不被修改晴弃。

秦凱月師姐總結(jié)

一、SSL握手有三個(gè)目的

1. 客戶端與服務(wù)器需要就一組用于保護(hù)數(shù)據(jù)的算法達(dá)成一致逊拍；

2. 它們需要確立一組由那些算法所使用的加密密鑰上鞠；

3. 握手還可以選擇對(duì)客戶端進(jìn)行認(rèn)證。

二芯丧、SSL握手過程

[圖片上傳失敗...(image-6f4b58-1534685167796)]

1. 客戶端將它所支持的算法列表和一個(gè)用作產(chǎn)生密鑰的隨機(jī)數(shù)發(fā)送給服務(wù)器芍阎；

2. 服務(wù)器從算法列表中選擇一種加密算法，并將它和一份包含服務(wù)器公用密鑰的證書發(fā)送給客戶端缨恒；該證書還包含了用于認(rèn)證目的的服務(wù)器標(biāo)識(shí)谴咸，服務(wù)器同時(shí)還提供了一個(gè)用作產(chǎn)生密鑰的隨機(jī)數(shù)；

3. 客戶端對(duì)服務(wù)器的證書進(jìn)行驗(yàn)證(有關(guān)驗(yàn)證證書骗露，可以參考數(shù)字簽名)岭佳，并抽取服務(wù)器的公用密鑰；然后椒袍，再產(chǎn)生一個(gè)稱作pre_master_secret的隨機(jī)密碼串驼唱，并使用服務(wù)器的公用密鑰對(duì)其進(jìn)行加密(參考非對(duì)稱加/解密)藻茂，并將加密后的信息發(fā)送給服務(wù)器驹暑；

4. 客戶端與服務(wù)器端根據(jù)pre_master_secret以及客戶端與服務(wù)器的隨機(jī)數(shù)值獨(dú)立計(jì)算出加密和MAC密鑰(參考DH密鑰交換算法)玫恳。

5. 客戶端將所有握手消息的MAC值發(fā)送給服務(wù)器；

6. 服務(wù)器將所有握手消息的MAC值發(fā)送給客戶端优俘。

第5與第6步用以防止握手本身遭受篡改京办。設(shè)想一個(gè)攻擊者想要控制客戶端與服務(wù)器所使用的算法》溃客戶端提供多種算法的情況相當(dāng)常見惭婿，某些強(qiáng)度弱而某些強(qiáng)度強(qiáng)，以便能夠與僅支持弱強(qiáng)度算法的服務(wù)器進(jìn)行通信叶雹。攻擊者可以刪除客戶端在第1步所提供的所有高強(qiáng)度算法财饥，于是就迫使服務(wù)器選擇一種弱強(qiáng)度的算法。第5步與第6步的MAC交換就能阻止這種攻擊折晦，因?yàn)榭蛻舳说腗AC是根據(jù)原始消息計(jì)算得出的钥星，而服務(wù)器的MAC是根據(jù)攻擊者修改過的消息計(jì)算得出的，這樣經(jīng)過檢查就會(huì)發(fā)現(xiàn)不匹配满着。由于客戶端與服務(wù)器所提供的隨機(jī)數(shù)為密鑰產(chǎn)生過程的輸入谦炒，所以握手不會(huì)受到重放攻擊的影響。這些消息是首個(gè)在新的加密算法與密鑰下加密的消息风喇。

剛才所描述的每一步都需要通過一條或多條握手消息來實(shí)現(xiàn)宁改。在此先簡要地描述哪些消息與哪幾步相對(duì)應(yīng)，然后詳細(xì)描述每條消息的內(nèi)容魂莫。下圖描述了各條消息：

[圖片上傳失敗...(image-5fbd7c-1534685167796)]

第1步對(duì)應(yīng)一條單一的握手消息还蹲，ClientHello.

第2步對(duì)應(yīng)一系列SSL握手消息，服務(wù)器發(fā)送的第一條消息為ServerHello耙考，其中包含了它所選擇的算法秽誊，接著再在Certificate消息中發(fā)送其證書。最后琳骡，服務(wù)器發(fā)送ServerHelloDone消息以表示這一握手階段的完成锅论。需要ServerHelloDone的原因是一些更為復(fù)雜的握手變種還要在Certifacate之后發(fā)送其他一些消息。當(dāng)客戶端接收到ServerHelloDone消息時(shí)楣号，它就知道不會(huì)再有其他類似的消息過來了最易，于是就可以繼續(xù)它這一方的握手。

第3步對(duì)應(yīng)ClientKeyExchange消息炫狱。

第5與第6步對(duì)應(yīng)Finished消息藻懒。該消息是第一條使用剛剛磋商過的算法加以保護(hù)的消息。為了防止握手過程遭到篡改视译，該消息的內(nèi)容是前一階段所有握手消息的MAC值嬉荆。然而，由于Finished消息是以磋商好的算法加以保護(hù)的酷含，所以也要與新磋商的MAC密鑰—起計(jì)算消息本身的MAC值鄙早。

注意汪茧，上圖中省略了兩條ChangeCipherSpec消息。