三年前寫(xiě)的文章，最近在整理資料時(shí)發(fā)現(xiàn)這篇沒(méi)發(fā)布過(guò)，就順便分享出來(lái)，希望能幫到有需要的人。

一點(diǎn)點(diǎn)歷史回顧

ARPAnet Reference Model

1969年11月，美國(guó)國(guó)防部 高級(jí)研究計(jì)劃管理局（ ARPA 全稱(chēng)： Advanced Research Projects Agency）開(kāi)始建立一個(gè)命名為ARPAnet的網(wǎng)絡(luò)，這是就是互聯(lián)網(wǎng)的前身，一個(gè)軍事用途的網(wǎng)絡(luò)。

TCP/IP Reference Model

隨著ARPAnet網(wǎng)絡(luò)的逐漸發(fā)展，更多的主機(jī)接入，原來(lái)的架構(gòu)和協(xié)議已經(jīng)不夠用了，研究人員把重點(diǎn)投向了第二代網(wǎng)絡(luò)協(xié)議的研究，于是TCP/IP協(xié)議簇出現(xiàn)了。而TCP/IP簇使用的網(wǎng)絡(luò)參考模型就是TCP/IP參考模型，我們稱(chēng)之為“五層網(wǎng)絡(luò)模型”。

當(dāng)然也有人說(shuō)這個(gè)TCP/IP參考模型是四層的，不是五層的。其實(shí)這么理解也是對(duì)的，TCP/IP參考模型只是一種概念，并沒(méi)有相關(guān)的標(biāo)準(zhǔn)。TCP/IP協(xié)議里邊 只是要求能夠提供給其上層-網(wǎng)絡(luò)互連層（Internet layer）一個(gè)訪(fǎng)問(wèn)接口，以便在其上傳遞IP分組就可以。由于這一層次未被定義，所以其具體的實(shí)現(xiàn)方法將隨著網(wǎng)絡(luò)類(lèi)型的不同而不同。

tcp5層示意圖.png

OSI Reference Model

全稱(chēng)Open Systems Interconnection Reference Model，即“開(kāi)放式系統(tǒng)互連參考模型”，是七層參考模型。

1978年（或1979年），為了統(tǒng)一網(wǎng)絡(luò)系統(tǒng)的體系結(jié)構(gòu)，ISO（International Standards Organization國(guó)際標(biāo)準(zhǔn)化組織）和CCITT（International Telegraph and Telephone Consultative Committee國(guó)際電報(bào)電話(huà)咨詢(xún)委員會(huì)）分別起草了定義網(wǎng)絡(luò)模型的文檔。1983年，這兩份文檔合并，形成一個(gè)標(biāo)準(zhǔn)，稱(chēng)為開(kāi)放系統(tǒng)互連的基本參考模型（the OSI Reference Model）。它把通信系統(tǒng)劃分成七個(gè)不同的抽象層，每一層服務(wù)于上一層，并由下面的層提供服務(wù)。1984年，該標(biāo)準(zhǔn)分別被列入了ISO標(biāo)準(zhǔn)（ISO 7498) 和 CCITT標(biāo)準(zhǔn)（X.200）。

osi7層數(shù)據(jù)圖解.jpeg

TCP/IP參考模型 和 OSI參考模型

無(wú)論是TCP/IP四層模型還是OSI七層模型，簡(jiǎn)單來(lái)講，發(fā)送數(shù)據(jù)的時(shí)候就是數(shù)據(jù)經(jīng)過(guò)層層包裝，包裝成每一層能看得明白的信息，然后到了物理層轉(zhuǎn)化成了二進(jìn)制流，發(fā)送出去，接收方再經(jīng)過(guò)逆向的層層剝離，把數(shù)據(jù)拿出來(lái)，最后就完成了數(shù)據(jù)的傳輸。

tcp4層和osi7層圖.jpeg

無(wú)論OSI 或TCP/IP 參考模型都有成功和不足的方面。ISO本來(lái)計(jì)劃通過(guò)推動(dòng)OSI參考模型與協(xié)議的研究來(lái)促進(jìn)網(wǎng)絡(luò)標(biāo)準(zhǔn)化，但是事實(shí)上這個(gè)目標(biāo)沒(méi)有達(dá)到。TCP/IP 協(xié)議利用正確的策略，抓住有利的時(shí)機(jī)，伴隨著互聯(lián)網(wǎng)發(fā)展而成為目前公認(rèn)的工業(yè)標(biāo)準(zhǔn)。在網(wǎng)絡(luò)標(biāo)準(zhǔn)化的進(jìn)程中，人們面對(duì)著的就是這樣一個(gè)事實(shí)。OSI 參考模型由于要照顧各方面的因素，使得OSI參考模型變得大而全、效率低。盡管這樣，它的很多研究結(jié)果、方法對(duì)今后網(wǎng)絡(luò)的發(fā)展有很好的指導(dǎo)意義、并且經(jīng)常被用于教學(xué)。TCP/IP 協(xié)議的應(yīng)用非常廣泛，但是它的參考模型研究卻很薄弱。

Http和Https的關(guān)系

HTTP通信，是不加密的通信。所有信息明文傳播，帶來(lái)了三大風(fēng)險(xiǎn)。

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

而SSL/TLS協(xié)議的誕生便是為了解決這三大風(fēng)險(xiǎn)：

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

HTTPS就是在TCP協(xié)議層和HTTP協(xié)議層中間架起了一層SSL/TSL協(xié)議層，這一層能夠把在網(wǎng)絡(luò)中傳輸?shù)臄?shù)據(jù)進(jìn)行有效的加密。下面是基于SSL協(xié)議的五層網(wǎng)絡(luò)模型圖：

https支持單向認(rèn)證（只驗(yàn)證服務(wù)端證書(shū)的有效性），也支持雙向驗(yàn)證（既驗(yàn)證服務(wù)端證書(shū)的有效性也驗(yàn)證客戶(hù)端證書(shū)的有效性）

SSL/TLS

SSL（Secure Sockets Layer安全套接層），是一種網(wǎng)絡(luò)安全協(xié)議。主要依賴(lài)數(shù)字證書(shū)、非對(duì)稱(chēng)加密、對(duì)稱(chēng)加密、數(shù)據(jù)完整性校驗(yàn)以及隨機(jī)數(shù)這5個(gè)密碼學(xué)的基礎(chǔ)知識(shí)，構(gòu)建出一個(gè)完整可信的傳輸鏈。

TLS（Transport Layer Security傳輸層安全協(xié)議），是基于SSL協(xié)議的通用化協(xié)議，正逐步替代SSL。

SSL/TLS分為兩層，一層是記錄協(xié)議（建立在可靠的傳輸協(xié)議上（比如tcp），提供數(shù)據(jù)封裝，加密解密，數(shù)據(jù)建議等基本功能），一層是握手協(xié)議（建立在記錄協(xié)議上，在實(shí)際的數(shù)據(jù)傳輸開(kāi)始前，進(jìn)行加密算法的協(xié)商，通信密鑰的交換等）。

SSL/TLS發(fā)展歷史

• 1994年，NetScape公司設(shè)計(jì)了SSL協(xié)議（Secure Sockets Layer）的1.0版，但是未發(fā)布。
• 1995年，NetScape公司發(fā)布SSL 2.0版，很快發(fā)現(xiàn)有嚴(yán)重漏洞。
• 1996年，SSL 3.0版問(wèn)世，得到大規(guī)模應(yīng)用。
• 1999年，互聯(lián)網(wǎng)標(biāo)準(zhǔn)化組織ISOC接替NetScape公司，發(fā)布了SSL的升級(jí)版TLS 1.0版。
• 2006年和2008年，TLS進(jìn)行了兩次升級(jí)，分別為T(mén)LS 1.1版和TLS 1.2版。
• 2011年，ISOC又發(fā)布了TLS 1.2的修訂版。

目前，應(yīng)用最廣泛的是TLS 1.0，接下來(lái)是SSL 3.0。但是，主流瀏覽器都已經(jīng)實(shí)現(xiàn)了TLS 1.2的支持。TLS 1.0通常被標(biāo)示為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。

基本運(yùn)行過(guò)程

SSL/TLS協(xié)議的基本思路是采用公鑰加密法，也就是說(shuō)，客戶(hù)端先向服務(wù)器端索要公鑰，然后用公鑰加密信息并發(fā)送給服務(wù)器，服務(wù)器收到密文后，用自己的私鑰解密。

那么，非對(duì)稱(chēng)加密的引入是否解決了數(shù)據(jù)傳輸?shù)陌踩珕?wèn)題？這個(gè)問(wèn)題大家可以思考一下，我們稍后再討論。

另外，細(xì)心的人都會(huì)發(fā)現(xiàn)，非對(duì)稱(chēng)加密機(jī)制的安全性，必須建立在公鑰的安全發(fā)放這個(gè)大前提上。畢竟在大多數(shù)情況下，通信雙方并不是面對(duì)面的，無(wú)法通過(guò)安全可靠的物理介質(zhì)交換公鑰，公鑰本身也是通過(guò)網(wǎng)絡(luò)傳輸?shù)?，那么，如何防止公鑰的傳輸過(guò)程被攻擊？舉個(gè)簡(jiǎn)單的例子，A和B為了通信安全，約定使用非對(duì)稱(chēng)加密進(jìn)行通信，在開(kāi)始加密通信前，B需要通過(guò)網(wǎng)絡(luò)向A發(fā)放自己的公鑰B’和一段密文，但此時(shí)C截獲了B‘的發(fā)放過(guò)程，將自己偽裝成B，并將自己的公鑰C‘和自己的私鑰加密的一段密文發(fā)放給了A，A拿到C’后，驗(yàn)證解密過(guò)程成功，就以為自己拿到的確實(shí)是B‘，于是開(kāi)始了加密通信，這樣，A和B都以為自己在和對(duì)方通信，但實(shí)際上他們其實(shí)各自在和C通信，此時(shí)C就可以為所欲為。

針對(duì)公鑰的安全發(fā)放問(wèn)題，解決辦法就是數(shù)字證書(shū)。私鑰持有者需要向CA購(gòu)買(mǎi)數(shù)字證書(shū)，將公鑰放在數(shù)字證書(shū)中傳輸，任何第三方只要驗(yàn)證了數(shù)字證書(shū)是可信的，就可以相信該證書(shū)中的公鑰是可信的。

然而，細(xì)心的人可能又有疑問(wèn)了：數(shù)字證書(shū)會(huì)不會(huì)也存在問(wèn)題，換句話(huà)說(shuō)，如何保證數(shù)字證書(shū)的有效安全？

數(shù)字證書(shū)的非法可能有兩種情況：

1. 證書(shū)是偽造的：壓根不是CA機(jī)構(gòu)頒發(fā)的證書(shū)；
2. 證書(shū)被篡改過(guò)：比如將證書(shū)中的公鑰給換了；

數(shù)字證書(shū)的可靠性，就要靠數(shù)字簽名來(lái)保證了。關(guān)于數(shù)字證書(shū)和數(shù)字簽名的詳細(xì)介紹，參考我的另一篇文章《信息安全的護(hù)城河：數(shù)字證書(shū)與數(shù)字簽名技術(shù)》，這里不再贅述。

解決了證書(shū)的安全發(fā)放問(wèn)題后，再回頭看第一個(gè)問(wèn)題：非對(duì)稱(chēng)加密的引入是否解決了數(shù)據(jù)傳輸?shù)陌踩珕?wèn)題？

答案是，還不夠！

為什么這么說(shuō)？因?yàn)榉菍?duì)稱(chēng)加密只能保證數(shù)據(jù)的傳輸單向安全。所謂非對(duì)稱(chēng)加密，就是一方加密的信息，只能由另一方解密。雖然私鑰只有自己（服務(wù)器）持有，但是公鑰卻是公開(kāi)的，任何人都可以持有公鑰，那么服務(wù)器用私鑰加密過(guò)的信息，任何持有公鑰的人都可以解密出來(lái)，換句話(huà)說(shuō)，服務(wù)器的數(shù)據(jù)相當(dāng)于是在網(wǎng)絡(luò)上換了種方式裸奔。

※引申思考：既然私鑰加密的數(shù)據(jù)并沒(méi)有隱私性可言，是不是私鑰加密就沒(méi)有用處了？

說(shuō)到這里，你可能會(huì)有疑惑：加入了SSL加密層，服務(wù)器數(shù)據(jù)還是在裸奔，還不如直接用HTTP來(lái)的省事。

非也非也，單純的非對(duì)稱(chēng)加密確實(shí)只能保證數(shù)據(jù)傳輸?shù)膯蜗虬踩Ｈ欢鳶SL不僅用了非對(duì)稱(chēng)加密，同時(shí)還結(jié)合了對(duì)稱(chēng)加密機(jī)制，來(lái)確保數(shù)據(jù)傳輸?shù)碾p向安全，而這同時(shí)也解決了非對(duì)稱(chēng)加密效率過(guò)低的弊病。

概括來(lái)說(shuō)，整個(gè)簡(jiǎn)化的加密通信的流程就是：

1. 客戶(hù)端訪(fǎng)問(wèn)服務(wù)器，服務(wù)器將自己的證書(shū)給到客戶(hù)端（瀏覽器）
2. 瀏覽器從證書(shū)中拿到服務(wù)器的公鑰A
3. 瀏覽器生成一個(gè)只有自己知道的對(duì)稱(chēng)密鑰B，用公鑰A加密，并傳給服務(wù)器（其實(shí)是有協(xié)商的過(guò)程，這里為了便于理解先簡(jiǎn)化）
4. 服務(wù)器通過(guò)私鑰解密，拿到對(duì)稱(chēng)密鑰B
5. 瀏覽器、服務(wù)器之后的數(shù)據(jù)通信，都用密鑰B進(jìn)行加密

上述過(guò)程的前4步，又稱(chēng)為“握手階段”。

SSL/TLS握手階段的詳細(xì)過(guò)程

握手階段圖解.png

1.客戶(hù)端發(fā)出請(qǐng)求（ClientHello）

首先，客戶(hù)端（通常是瀏覽器）先向服務(wù)器發(fā)出加密通信的請(qǐng)求，這被叫做ClientHello請(qǐng)求。

在這一步，客戶(hù)端主要向服務(wù)器提供以下信息：

• 支持的協(xié)議版本，比如TLS 1.0版。
• 一個(gè)客戶(hù)端生成的隨機(jī)數(shù)A，稍后用于生成"對(duì)話(huà)密鑰"。
• 支持的加密方法，比如RSA公鑰加密。
• 支持的壓縮方法。

2.服務(wù)器回應(yīng)（SeverHello）

服務(wù)器收到客戶(hù)端請(qǐng)求后，向客戶(hù)端發(fā)出回應(yīng)，這叫做SeverHello。

服務(wù)器的回應(yīng)包含以下內(nèi)容：

• 確認(rèn)使用的加密通信協(xié)議版本，比如TLS 1.0版本。如果瀏覽器與服務(wù)器支持的版本不一致，服務(wù)器關(guān)閉加密通信。
• 一個(gè)服務(wù)器生成的隨機(jī)數(shù)B，稍后用于生成"對(duì)話(huà)密鑰"。
• 確認(rèn)使用的加密方法，比如RSA公鑰加密。
• 服務(wù)器證書(shū)。

除此之外，如果服務(wù)器需要使用雙向認(rèn)證，就會(huì)再包含一項(xiàng)請(qǐng)求，要求客戶(hù)端提供"客戶(hù)端證書(shū)"。比如，金融機(jī)構(gòu)往往只允許認(rèn)證客戶(hù)連入自己的網(wǎng)絡(luò)，就會(huì)向正式客戶(hù)提供USB密鑰，里面就包含了一張客戶(hù)端證書(shū)。

3.客戶(hù)端回應(yīng)

客戶(hù)端收到服務(wù)器回應(yīng)以后，首先驗(yàn)證服務(wù)器證書(shū)。如果證書(shū)不是可信機(jī)構(gòu)頒布、或者證書(shū)中的域名與實(shí)際域名不一致、或者證書(shū)已經(jīng)過(guò)期，就會(huì)向訪(fǎng)問(wèn)者顯示一個(gè)警告，由其選擇是否還要繼續(xù)通信。

如果證書(shū)沒(méi)有問(wèn)題，客戶(hù)端就會(huì)從證書(shū)中取出服務(wù)器的公鑰。然后，向服務(wù)器發(fā)送下面三項(xiàng)信息。

• 一個(gè)隨機(jī)數(shù)C。該隨機(jī)數(shù)用服務(wù)器公鑰加密，防止被竊聽(tīng)。
• 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。
• 客戶(hù)端握手結(jié)束通知，表示客戶(hù)端的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值，用來(lái)供服務(wù)器校驗(yàn)。

上面的隨機(jī)數(shù)C，是整個(gè)握手階段出現(xiàn)的第三個(gè)隨機(jī)數(shù)，又稱(chēng)"pre-master key"。有了它以后，客戶(hù)端和服務(wù)器就同時(shí)有了三個(gè)隨機(jī)數(shù)，接著雙方就用事先商定的加密方法，各自生成本次會(huì)話(huà)所用的同一把"會(huì)話(huà)密鑰"。

此外，如果前一步，服務(wù)器要求客戶(hù)端證書(shū)，客戶(hù)端會(huì)在這一步發(fā)送證書(shū)及相關(guān)信息。

4.服務(wù)器的最后回應(yīng)

服務(wù)器收到客戶(hù)端的第三個(gè)隨機(jī)數(shù)pre-master key之后，計(jì)算生成本次會(huì)話(huà)所用的"會(huì)話(huà)密鑰"（對(duì)稱(chēng)密鑰）。然后，向客戶(hù)端最后發(fā)送下面信息。
（1）編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。
（2）服務(wù)器握手結(jié)束通知，表示服務(wù)器的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值，用來(lái)供客戶(hù)端校驗(yàn)。

至此，整個(gè)握手階段全部結(jié)束。接下來(lái)，客戶(hù)端與服務(wù)器進(jìn)入加密通信，就完全是使用普通的HTTP協(xié)議，只不過(guò)用"會(huì)話(huà)密鑰"加密內(nèi)容。

為什么是三個(gè)隨機(jī)數(shù)？

整個(gè)握手階段為什么要用三個(gè)隨機(jī)數(shù)來(lái)生成“會(huì)話(huà)密鑰”，網(wǎng)友 Bomb250 的解釋很好：

"不管是客戶(hù)端還是服務(wù)器，都需要隨機(jī)數(shù)，這樣生成的密鑰才不會(huì)每次都一樣。由于SSL協(xié)議中證書(shū)是靜態(tài)的，因此十分有必要引入一種隨機(jī)因素來(lái)保證協(xié)商出來(lái)的密鑰的隨機(jī)性。

對(duì)于RSA密鑰交換算法來(lái)說(shuō)，pre-master-key本身就是一個(gè)隨機(jī)數(shù)，再加上hello消息中的隨機(jī)，三個(gè)隨機(jī)數(shù)通過(guò)一個(gè)密鑰導(dǎo)出器最終導(dǎo)出一個(gè)對(duì)稱(chēng)密鑰。

pre master的存在在于SSL協(xié)議不信任每個(gè)主機(jī)都能產(chǎn)生完全隨機(jī)的隨機(jī)數(shù)，如果隨機(jī)數(shù)不隨機(jī)，那么pre master secret就有可能被猜出來(lái)，那么僅使用pre master secret作為密鑰就不合適了，因此必須引入新的隨機(jī)因素，那么客戶(hù)端和服務(wù)器加上pre master secret三個(gè)隨機(jī)數(shù)一同生成的密鑰就不容易被猜出了，一個(gè)偽隨機(jī)可能完全不隨機(jī)，但是三個(gè)偽隨機(jī)就十分接近隨機(jī)了，每增加一個(gè)自由度，隨機(jī)性增加的可不是一。"

為什么更加安全的HTTPS沒(méi)有在互聯(lián)網(wǎng)中全面應(yīng)用

• SSL 證書(shū)需要錢(qián)。功能越強(qiáng)大的證書(shū)費(fèi)用越高。個(gè)人網(wǎng)站、小網(wǎng)站沒(méi)有必要一般不會(huì)用。
• SSL 證書(shū)通常需要綁定 IP，不能在同一 IP 上綁定多個(gè)域名。IPv4 資源不可能支撐這個(gè)消耗。（ SSL 有擴(kuò)展可以部分解決這個(gè)問(wèn)題，但是比較麻煩，而且要求瀏覽器、操作系統(tǒng)支持。Windows XP 就不支持這個(gè)擴(kuò)展，考慮到 XP 的裝機(jī)量，這個(gè)特性幾乎沒(méi)用。）
• HTTPS 連接緩存不如 HTTP 高效，大流量網(wǎng)站如非必要也不會(huì)采用。流量成本太高。
• HTTPS 連接服務(wù)器端資源占用高很多，支持訪(fǎng)客稍多的網(wǎng)站需要投入更大的成本。如果全部采用 HTTPS，基于大部分計(jì)算資源閑置的假設(shè)的 VPS 的平均成本會(huì)上去。
• HTTPS 協(xié)議握手階段比較費(fèi)時(shí)，對(duì)網(wǎng)站的響應(yīng)速度有負(fù)面影響。如非必要，沒(méi)有理由犧牲用戶(hù)體驗(yàn)。
• 最關(guān)鍵的，SSL 證書(shū)的信用鏈體系并不安全。特別是在某些國(guó)家（咳咳，你們懂的）可以控制CA 根證書(shū)的情況下，中間人攻擊一樣可行。
• 對(duì)于大型網(wǎng)站來(lái)說(shuō)，換成SSL要保證跟你合作的所有服務(wù)都支持SSL。服務(wù)器設(shè)置也會(huì)更麻煩。

Stackoverflow 的創(chuàng)始人也曾經(jīng)針對(duì)為什么Stackoverflow不使用https做出了回答：Stackoverflow.com: the road to SSL ? Nick Craver

中間人攻擊

關(guān)于HTTPS，經(jīng)常會(huì)提到的就是中間人攻擊，即所謂的Man-in-the-middle attack(MITM)，顧名思義，就是攻擊者插入到原本直接通信的雙方，讓雙方以為還在直接跟對(duì)方通訊，但實(shí)際上雙方的通信對(duì)方已變成了中間人，信息已經(jīng)被中間人獲取或篡改。

中間人攻擊.png

1.SSL證書(shū)欺騙攻擊

此類(lèi)攻擊較為簡(jiǎn)單常見(jiàn)。首先通過(guò)ARP欺騙、DNS劫持甚至網(wǎng)關(guān)劫持等等，將客戶(hù)端的訪(fǎng)問(wèn)重定向到攻擊者的機(jī)器，讓客戶(hù)端機(jī)器與攻擊者機(jī)器建立HTTPS連接（使用偽造證書(shū)），而攻擊者機(jī)器再跟服務(wù)端連接。這樣用戶(hù)在客戶(hù)端看到的是相同域名的網(wǎng)站，但瀏覽器會(huì)提示證書(shū)不可信，用戶(hù)不點(diǎn)擊“繼續(xù)瀏覽”就能避免被劫持。所以這是最簡(jiǎn)單的攻擊方式，也是最容易識(shí)別的攻擊方式。

2.SSL剝離攻擊

SSL剝離，即將HTTPS連接降級(jí)到HTTP連接。假如客戶(hù)端直接訪(fǎng)問(wèn)HTTPS的URL，攻擊者是沒(méi)辦法直接進(jìn)行降級(jí)的，因?yàn)镠TTPS與HTTP雖然都是TCP連接，但HTTPS在傳輸HTTP數(shù)據(jù)之前，需要進(jìn)行SSL握手，并協(xié)商對(duì)稱(chēng)密鑰用于后續(xù)的加密傳輸；假如客戶(hù)端與攻擊者進(jìn)行SSL握手，而攻擊者無(wú)法提供可信任的證書(shū)來(lái)讓客戶(hù)端驗(yàn)證通過(guò)進(jìn)行連接，所以客戶(hù)端的系統(tǒng)會(huì)判斷為SSL握手失敗，斷開(kāi)連接。

該攻擊方式主要是利用用戶(hù)并不會(huì)每次都直接在瀏覽器上輸入https://xxx.xxx.com來(lái)訪(fǎng)問(wèn)網(wǎng)站，或者有些網(wǎng)站并非全網(wǎng)HTTPS，而是只在需要進(jìn)行敏感數(shù)據(jù)傳輸時(shí)才使用HTTPS的漏洞。中間人攻擊者在劫持了客戶(hù)端與服務(wù)端的HTTP會(huì)話(huà)后，將HTTP頁(yè)面里面所有的https://超鏈接都換成http://，用戶(hù)在點(diǎn)擊相應(yīng)的鏈接時(shí)，是使用HTTP協(xié)議來(lái)進(jìn)行訪(fǎng)問(wèn)；這樣，就算服務(wù)器對(duì)相應(yīng)的URL只支持HTTPS鏈接，但中間人一樣可以和服務(wù)建立HTTPS連接之后，將數(shù)據(jù)使用HTTP協(xié)議轉(zhuǎn)發(fā)給客戶(hù)端，實(shí)現(xiàn)會(huì)話(huà)劫持。

這種攻擊手段更讓人難以提防，因?yàn)樗褂肏TTP，不會(huì)讓瀏覽器出現(xiàn)HTTPS證書(shū)不可信的警告，而且用戶(hù)很少會(huì)去看瀏覽器上的URL是https://還是http://。特別是App的WebView中，應(yīng)用一般會(huì)把URL隱藏掉，用戶(hù)根本無(wú)法直接查看到URL出現(xiàn)異常。

SSL剝離攻擊.png

老和尚和小和尚的故事

作者：牟旭東

鏈接：https://www.zhihu.com/question/21518760/answer/19698894

來(lái)源：知乎

著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。

下面開(kāi)始講一個(gè)無(wú)聊的故事，和問(wèn)題關(guān)系不大，時(shí)間緊張的看官可以到此為止了。

從前山上有座廟，廟里有個(gè)和尚......，別胡鬧了，老和尚來(lái)了。

小和尚問(wèn)老和尚：ssl為什么會(huì)讓http安全？

老和尚答道：譬如你我都有一個(gè)同樣的密碼，我發(fā)信給你時(shí)用這個(gè)密碼加密，你收到我發(fā)的信，用這個(gè)密碼解密，就能知道我信的內(nèi)容，其他的閑雜人等，就算偷偷拿到了信，由于不知道這個(gè)密碼，也只能望信興嘆，這個(gè)密碼就叫做對(duì)稱(chēng)密碼。ssl使用對(duì)稱(chēng)密碼對(duì)http內(nèi)容進(jìn)行加解密，所以讓http安全了，常用的加解密算法主要有3DES和AES等。

小和尚摸摸腦袋問(wèn)老和尚：師傅，如果我們兩人選擇“和尚”作為密碼，再創(chuàng)造一個(gè)和尚算法，我們倆之間的通信不就高枕無(wú)憂(yōu)了？
老和尚當(dāng)頭給了小和尚一戒尺：那我要給山下的小花寫(xiě)情書(shū)，還得用“和尚”這個(gè)密碼不成？想了想又給了小和尚一戒尺：雖然我們是和尚，不是碼農(nóng)，也不能自己造輪子，當(dāng)初一堆牛人碼農(nóng)造出了Wifi的安全算法WEP，后來(lái)發(fā)現(xiàn)是一繡花枕頭，在安全界傳為笑談；況且小花只知道3DES和AES，哪知道和尚算法？

小和尚問(wèn)到：那師傅何解？

老和尚：我和小花只要知道每封信的密碼，就可以讀到對(duì)方加密的信件，關(guān)鍵是我們互相之間怎么知道這個(gè)對(duì)稱(chēng)密碼。你說(shuō)，我要是將密碼寫(xiě)封信給她，信被別人偷了，那大家不都知道我們的密碼了，也就能夠讀懂我們情書(shū)了。不過(guò)還是有解的，這里我用到了江湖中秘傳的非對(duì)稱(chēng)密碼。我現(xiàn)在手頭有兩個(gè)密碼，一個(gè)叫“公鑰”，一個(gè)叫“私鑰”，公鑰發(fā)布到了江湖上，好多人都知道，私鑰嘛，江湖上只有我一個(gè)人知道；這兩個(gè)密鑰有數(shù)學(xué)相關(guān)性，就是說(shuō)用公鑰加密的信件，可以用私鑰解開(kāi)，但是用公鑰卻解不開(kāi)。公鑰小花是知道的，她每次給我寫(xiě)信，都要我的公鑰加密她的對(duì)稱(chēng)密碼，單獨(dú)寫(xiě)一張密碼紙，然后用她的對(duì)稱(chēng)密碼加密她的信件，這樣我用我的私鑰可以解出這個(gè)對(duì)稱(chēng)密碼，再用這個(gè)對(duì)稱(chēng)密碼來(lái)解密她的信件。

老和尚頓了頓：可惜她用的對(duì)稱(chēng)密碼老是“和尚為什么寫(xiě)情書(shū)”這一類(lèi)，所以我每次解開(kāi)密碼紙時(shí)總是悵然若失，其實(shí)我鐘意的對(duì)稱(chēng)密碼是諸如“風(fēng)花”“雪月”什么的，最頭痛的是，我還不得不用“和尚為什么寫(xiě)情書(shū)”這個(gè)密碼來(lái)加密我給小花回的情書(shū)，人世間最痛苦的事莫過(guò)于如此?？晌夷睦镏溃鋵?shí)有人比我更痛苦。山下的張屠夫，暗戀小花很多年，看著我們鴻雁傳書(shū)，心中很不是滋味，主動(dòng)毛遂自薦代替香客給我們送信。在他第一次給小花送信時(shí)，就給了小花他自己的公鑰，謊稱(chēng)是我公鑰剛剛更新了，小花信以為真，之后的信件對(duì)稱(chēng)密碼都用張屠夫的這個(gè)公鑰加密了，張屠夫拿到回信后，用他自己的私鑰解開(kāi)了小花的對(duì)稱(chēng)密碼，然后用這個(gè)對(duì)稱(chēng)密碼，不僅能夠看到了小花信件的所有內(nèi)容，還能使用這個(gè)密碼偽造小花給我寫(xiě)信，同時(shí)還能用他的私鑰加密給小花的信件。漸漸我發(fā)現(xiàn)信件變味了，盡管心生疑惑，但是沒(méi)有確切的證據(jù)，一次我寫(xiě)信問(wèn)小花第一次使用的對(duì)稱(chēng)密碼，回信中“和尚為什么寫(xiě)情書(shū)”赫然在列，于是我的疑惑稍稍減輕。直到有一次去拜會(huì)嵩山少林寺老方丈才頓悟，原來(lái)由于我的公鑰沒(méi)有火印，任何人都可以偽造一份公鑰宣稱(chēng)是我的，這樣這個(gè)人即能讀到別人寫(xiě)給我的信，也能偽造別人給我寫(xiě)信，同樣也能讀到我的回信，也能偽造我給別人的回信，這種邪門(mén)武功江湖上稱(chēng)之“Man-in-the-middle attack”。唯一的破解就是使用嵩山少林寺的火印，這個(gè)火印可有講究了，需要將我的公鑰及個(gè)人在江湖地位提交給18羅漢委員會(huì)，他們會(huì)根據(jù)我的這些信息使用委員會(huì)私鑰進(jìn)行數(shù)字簽名，簽名的信息凸現(xiàn)在火印上，有火印的公鑰真實(shí)性在江湖上無(wú)人質(zhì)疑，要知道18羅漢可是無(wú)人敢得罪的。

小和尚問(wèn)：那然后呢？

老和尚：從嵩山少林寺回山上寺廟時(shí)，我將有火印的公鑰親自給小花送去，可是之后再也沒(méi)有收到小花的來(lái)信。過(guò)了一年才知道，其實(shí)小花還是給我寫(xiě)過(guò)信的，當(dāng)時(shí)信確實(shí)是用有火印的公鑰加密，張屠夫拿到信后，由于不知道我的私鑰，解不開(kāi)小花的密碼信，所以一怒之下將信件全部燒毀了。也由于張屠夫無(wú)法知道小花的對(duì)稱(chēng)密碼而無(wú)法回信，小花發(fā)出幾封信后石沉大海，也心生疑惑，到處打聽(tīng)我的近況。這下張屠夫急了，他使用我發(fā)布的公鑰，仿照小花的語(yǔ)氣，給我發(fā)來(lái)一封信。拿到信時(shí)我就覺(jué)得奇怪，信紙上怎么有一股豬油的味道，結(jié)尾竟然還關(guān)切的詢(xún)問(wèn)我的私鑰。情知有詐，我思量無(wú)論如何要找到辦法讓我知道來(lái)的信是否真是小花所寫(xiě)。后來(lái)竟然讓我想到了辦法....

老和尚摸著光頭說(shuō)：這頭發(fā)可不是白掉的，我托香客給小花帶話(huà)，我一切安好，希望她也擁有屬于自己的一段幸福，不對(duì)，是一對(duì)非對(duì)稱(chēng)密鑰。小花委托小鎮(zhèn)美女協(xié)會(huì)給小花公鑰打上火印后，托香客給我送來(lái)，這樣小花在每次給我寫(xiě)信時(shí)，都會(huì)在密碼紙上貼上一朵小牡丹，牡丹上寫(xiě)上用她自己的私鑰加密過(guò)的給我的留言，這樣我收到自稱(chēng)是小花的信后，我會(huì)先抽出密碼紙，取下小牡丹，使用小花的公鑰解密這段留言，如果解不出來(lái)，我會(huì)直接將整封信連同密碼紙一起扔掉，因?yàn)檫@封信一定不是小花寫(xiě)的，如果能夠解出來(lái)，這封信才能確信來(lái)之于小花，我才仔細(xì)的解碼閱讀。

小和尚：難怪聽(tīng)說(shuō)張屠夫是被活活氣死的。您這情書(shū)整的，我頭都大了，我長(zhǎng)大后，有想法直接扯著嗓子對(duì)山下喊，也省的這么些麻煩。不過(guò)我倒是明白了樓上的話(huà)，ssl 握手階段，就是要解決什么看火印，讀牡丹，解密碼紙，確實(shí)夠麻煩的，所以性能瓶頸在這里，一旦雙方都知道了對(duì)稱(chēng)密碼，之后就是行云流水的解碼讀信階段了，相對(duì)輕松很多。