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

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

ARPAnet Reference Model

1969年11月，美國(guó)國(guó)防部 高級(jí)研究計(jì)劃管理局（ ARPA 全稱： Advanced Research Projects Agency）開始建立一個(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參考模型，我們稱之為“五層網(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è)訪問(wèn)接口，以便在其上傳遞IP分組就可以采转。由于這一層次未被定義聪廉，所以其具體的實(shí)現(xiàn)方法將隨著網(wǎng)絡(luò)類型的不同而不同。

tcp5層示意圖.png

OSI Reference Model

全稱Open Systems Interconnection Reference Model故慈，即“開放式系統(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ì)）分別起草了定義網(wǎng)絡(luò)模型的文檔。1983年拆撼，這兩份文檔合并容劳，形成一個(gè)標(biāo)準(zhǔn)，稱為開放系統(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)。

• 竊聽風(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ú)法竊聽柑营。
• 具有校驗(yàn)機(jī)制，一旦被篡改玛迄，通信雙方會(huì)立刻發(fā)現(xiàn)由境。
• 配備身份證書，防止身份被冒充蓖议。

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ù)端證書的有效性）勒虾，也支持雙向驗(yàn)證（既驗(yàn)證服務(wù)端證書的有效性也驗(yàn)證客戶端證書的有效性）

SSL/TLS

SSL（Secure Sockets Layer安全套接層）纺阔，是一種網(wǎng)絡(luò)安全協(xié)議。主要依賴數(shù)字證書修然、非對(duì)稱加密笛钝、對(duì)稱加密、數(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ù)傳輸開始前挡毅，進(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í)，分別為TLS 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ō)桐腌，客戶端先向服務(wù)器端索要公鑰拄显，然后用公鑰加密信息并發(fā)送給服務(wù)器，服務(wù)器收到密文后案站，用自己的私鑰解密躬审。

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

另外舱禽，細(xì)心的人都會(huì)發(fā)現(xiàn)炒刁，非對(duì)稱加密機(jī)制的安全性，必須建立在公鑰的安全發(fā)放這個(gè)大前提上誊稚。畢竟在大多數(shù)情況下翔始，通信雙方并不是面對(duì)面的，無(wú)法通過(guò)安全可靠的物理介質(zhì)交換公鑰里伯，公鑰本身也是通過(guò)網(wǎng)絡(luò)傳輸?shù)某窍梗敲矗绾畏乐构€的傳輸過(guò)程被攻擊疾瓮？舉個(gè)簡(jiǎn)單的例子脖镀，A和B為了通信安全，約定使用非對(duì)稱加密進(jìn)行通信狼电，在開始加密通信前蜒灰，B需要通過(guò)網(wǎng)絡(luò)向A發(fā)放自己的公鑰B’和一段密文，但此時(shí)C截獲了B‘的發(fā)放過(guò)程肩碟，將自己偽裝成B强窖，并將自己的公鑰C‘和自己的私鑰加密的一段密文發(fā)放給了A，A拿到C’后削祈，驗(yàn)證解密過(guò)程成功翅溺，就以為自己拿到的確實(shí)是B‘，于是開始了加密通信髓抑，這樣咙崎，A和B都以為自己在和對(duì)方通信，但實(shí)際上他們其實(shí)各自在和C通信启昧，此時(shí)C就可以為所欲為叙凡。

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

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

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

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

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

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

答案是，還不夠悉盆！

為什么這么說(shuō)盯荤？因?yàn)榉菍?duì)稱加密只能保證數(shù)據(jù)的傳輸單向安全。所謂非對(duì)稱加密焕盟，就是一方加密的信息秋秤，只能由另一方解密。雖然私鑰只有自己（服務(wù)器）持有脚翘，但是公鑰卻是公開的航缀，任何人都可以持有公鑰，那么服務(wù)器用私鑰加密過(guò)的信息堰怨，任何持有公鑰的人都可以解密出來(lái)芥玉，換句話說(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ì)稱加密確實(shí)只能保證數(shù)據(jù)傳輸?shù)膯蜗虬踩Ｈ欢鳶SL不僅用了非對(duì)稱加密雪标，同時(shí)還結(jié)合了對(duì)稱加密機(jī)制零院，來(lái)確保數(shù)據(jù)傳輸?shù)碾p向安全，而這同時(shí)也解決了非對(duì)稱加密效率過(guò)低的弊病村刨。

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

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

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

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

握手階段圖解.png

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

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

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

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

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

服務(wù)器收到客戶端請(qǐng)求后设哗，向客戶端發(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ì)話密鑰"党涕。
• 確認(rèn)使用的加密方法烦感，比如RSA公鑰加密。
• 服務(wù)器證書膛堤。

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

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

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

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

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

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

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

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

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

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

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

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

"不管是客戶端還是服務(wù)器，都需要隨機(jī)數(shù)豁辉，這樣生成的密鑰才不會(huì)每次都一樣令野。由于SSL協(xié)議中證書是靜態(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ì)稱密鑰。

pre master的存在在于SSL協(xié)議不信任每個(gè)主機(jī)都能產(chǎn)生完全隨機(jī)的隨機(jī)數(shù)狗超，如果隨機(jī)數(shù)不隨機(jī)弹澎，那么pre master secret就有可能被猜出來(lái)，那么僅使用pre master secret作為密鑰就不合適了努咐，因此必須引入新的隨機(jī)因素苦蒿，那么客戶端和服務(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 證書需要錢报强。功能越強(qiáng)大的證書費(fèi)用越高。個(gè)人網(wǎng)站拱燃、小網(wǎng)站沒(méi)有必要一般不會(huì)用秉溉。
• SSL 證書通常需要綁定 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ù)器端資源占用高很多，支持訪客稍多的網(wǎng)站需要投入更大的成本凯肋。如果全部采用 HTTPS谊惭，基于大部分計(jì)算資源閑置的假設(shè)的 VPS 的平均成本會(huì)上去。
• HTTPS 協(xié)議握手階段比較費(fèi)時(shí)侮东，對(duì)網(wǎng)站的響應(yīng)速度有負(fù)面影響圈盔。如非必要，沒(méi)有理由犧牲用戶體驗(yàn)悄雅。
• 最關(guān)鍵的驱敲，SSL 證書的信用鏈體系并不安全。特別是在某些國(guó)家（咳咳宽闲，你們懂的）可以控制CA 根證書的情況下众眨，中間人攻擊一樣可行。
• 對(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證書欺騙攻擊

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

2.SSL剝離攻擊

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

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

這種攻擊手段更讓人難以提防奕谭，因?yàn)樗褂肏TTP，不會(huì)讓瀏覽器出現(xiàn)HTTPS證書不可信的警告痴荐，而且用戶很少會(huì)去看瀏覽器上的URL是https://還是http://血柳。特別是App的WebView中，應(yīng)用一般會(huì)把URL隱藏掉生兆，用戶根本無(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)注明出處根吁。

下面開始講一個(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ì)稱密碼寿烟。ssl使用對(duì)稱密碼對(duì)http內(nèi)容進(jìn)行加解密澈驼，所以讓http安全了，常用的加解密算法主要有3DES和AES等筛武。

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

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

老和尚：我和小花只要知道每封信的密碼随常，就可以讀到對(duì)方加密的信件，關(guān)鍵是我們互相之間怎么知道這個(gè)對(duì)稱密碼萄涯。你說(shuō)绪氛，我要是將密碼寫封信給她，信被別人偷了涝影，那大家不都知道我們的密碼了枣察，也就能夠讀懂我們情書了。不過(guò)還是有解的袄琳，這里我用到了江湖中秘傳的非對(duì)稱密碼询件。我現(xiàn)在手頭有兩個(gè)密碼燃乍，一個(gè)叫“公鑰”，一個(gè)叫“私鑰”宛琅，公鑰發(fā)布到了江湖上刻蟹，好多人都知道，私鑰嘛嘿辟，江湖上只有我一個(gè)人知道舆瘪；這兩個(gè)密鑰有數(shù)學(xué)相關(guān)性，就是說(shuō)用公鑰加密的信件红伦，可以用私鑰解開英古，但是用公鑰卻解不開。公鑰小花是知道的昙读，她每次給我寫信召调，都要我的公鑰加密她的對(duì)稱密碼，單獨(dú)寫一張密碼紙蛮浑，然后用她的對(duì)稱密碼加密她的信件唠叛，這樣我用我的私鑰可以解出這個(gè)對(duì)稱密碼，再用這個(gè)對(duì)稱密碼來(lái)解密她的信件沮稚。

老和尚頓了頓：可惜她用的對(duì)稱密碼老是“和尚為什么寫情書”這一類艺沼，所以我每次解開密碼紙時(shí)總是悵然若失，其實(shí)我鐘意的對(duì)稱密碼是諸如“風(fēng)花”“雪月”什么的蕴掏，最頭痛的是障般，我還不得不用“和尚為什么寫情書”這個(gè)密碼來(lái)加密我給小花回的情書，人世間最痛苦的事莫過(guò)于如此盛杰⊥斓矗可我哪里知道，其實(shí)有人比我更痛苦饶唤。山下的張屠夫徐伐，暗戀小花很多年贯钩，看著我們鴻雁傳書募狂，心中很不是滋味，主動(dòng)毛遂自薦代替香客給我們送信角雷。在他第一次給小花送信時(shí)祸穷，就給了小花他自己的公鑰，謊稱是我公鑰剛剛更新了勺三，小花信以為真雷滚，之后的信件對(duì)稱密碼都用張屠夫的這個(gè)公鑰加密了，張屠夫拿到回信后吗坚，用他自己的私鑰解開了小花的對(duì)稱密碼祈远，然后用這個(gè)對(duì)稱密碼呆万，不僅能夠看到了小花信件的所有內(nèi)容，還能使用這個(gè)密碼偽造小花給我寫信车份，同時(shí)還能用他的私鑰加密給小花的信件谋减。漸漸我發(fā)現(xiàn)信件變味了，盡管心生疑惑扫沼，但是沒(méi)有確切的證據(jù)出爹，一次我寫信問(wèn)小花第一次使用的對(duì)稱密碼，回信中“和尚為什么寫情書”赫然在列缎除，于是我的疑惑稍稍減輕严就。直到有一次去拜會(huì)嵩山少林寺老方丈才頓悟，原來(lái)由于我的公鑰沒(méi)有火印器罐，任何人都可以偽造一份公鑰宣稱是我的梢为，這樣這個(gè)人即能讀到別人寫給我的信，也能偽造別人給我寫信轰坊，同樣也能讀到我的回信抖誉，也能偽造我給別人的回信，這種邪門武功江湖上稱之“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í)小花還是給我寫過(guò)信的存谎，當(dāng)時(shí)信確實(shí)是用有火印的公鑰加密，張屠夫拿到信后肥隆，由于不知道我的私鑰既荚，解不開小花的密碼信，所以一怒之下將信件全部燒毀了栋艳。也由于張屠夫無(wú)法知道小花的對(duì)稱密碼而無(wú)法回信恰聘，小花發(fā)出幾封信后石沉大海，也心生疑惑，到處打聽我的近況晴叨。這下張屠夫急了凿宾，他使用我發(fā)布的公鑰，仿照小花的語(yǔ)氣兼蕊，給我發(fā)來(lái)一封信菌湃。拿到信時(shí)我就覺(jué)得奇怪，信紙上怎么有一股豬油的味道遍略，結(jié)尾竟然還關(guān)切的詢問(wèn)我的私鑰惧所。情知有詐，我思量無(wú)論如何要找到辦法讓我知道來(lái)的信是否真是小花所寫绪杏。后來(lái)竟然讓我想到了辦法....

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

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