三年前寫的文章，最近在整理資料時發現這篇沒發布過，就順便分享出來，希望能幫到有需要的人，

一點點歷史回顧

ARPAnet Reference Model

1969年11月，美國國防部 高級研究計劃管理局（ ARPA 全稱： Advanced Research Projects Agency）開始建立一個命名為ARPAnet的網路，這是就是互聯網的前身，一個軍事用途的網路，

TCP/IP Reference Model

隨著ARPAnet網路的逐漸發展，更多的主機接入，原來的架構和協議已經不夠用了，研究人員把重點投向了第二代網路協議的研究，于是TCP/IP協議簇出現了，而TCP/IP簇使用的網路參考模型就是TCP/IP參考模型，我們稱之為“五層網路模型”，

當然也有人說這個TCP/IP參考模型是四層的，不是五層的，其實這么理解也是對的，TCP/IP參考模型只是一種概念，并沒有相關的標準，TCP/IP協議里邊 只是要求能夠提供給其上層-網路互連層（Internet layer）一個訪問介面，以便在其上傳遞IP分組就可以，由于這一層次未被定義，所以其具體的實作方法將隨著網路型別的不同而不同，

OSI Reference Model

全稱Open Systems Interconnection Reference Model，即“開放式系統互連參考模型”，是七層參考模型，

1978年（或1979年），為了統一網路系統的體系結構，ISO（International Standards Organization國際標準化組織）和CCITT（International Telegraph and Telephone Consultative Committee國際電報電話咨詢委員會）分別起草了定義網路模型的檔案，1983年，這兩份檔案合并，形成一個標準，稱為開放系統互連的基本參考模型（the OSI Reference Model），它把通信系統劃分成七個不同的抽象層，每一層服務于上一層，并由下面的層提供服務，1984年，該標準分別被列入了ISO標準（ISO 7498) 和 CCITT標準（X.200），

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

無論是TCP/IP四層模型還是OSI七層模型，簡單來講，發送資料的時候就是資料經過層層包裝，包裝成每一層能看得明白的資訊，然后到了物理層轉化成了二進制流，發送出去，接收方再經過逆向的層層剝離，把資料拿出來，最后就完成了資料的傳輸，

無論OSI 或TCP/IP 參考模型都有成功和不足的方面，ISO本來計劃通過推動OSI參考模型與協議的研究來促進網路標準化，但是事實上這個目標沒有達到，TCP/IP 協議利用正確的策略，抓住有利的時機，伴隨著互聯網發展而成為目前公認的工業標準，在網路標準化的行程中，人們面對著的就是這樣一個事實，OSI 參考模型由于要照顧各方面的因素，使得OSI參考模型變得大而全、效率低，盡管這樣，它的很多研究結果、方法對今后網路的發展有很好的指導意義、并且經常被用于教學，TCP/IP 協議的應用非常廣泛，但是它的參考模型研究卻很薄弱，

Http和Https的關系

HTTP通信，是不加密的通信，所有資訊明文傳播，帶來了三大風險，

• 竊聽風險（eavesdropping）：第三方可以獲知通信內容，
• 篡改風險（tampering）：第三方可以修改通信內容，
• 冒充風險（pretending）：第三方可以冒充他人身份參與通信，

而SSL/TLS協議的誕生便是為了解決這三大風險：

• 所有資訊都是加密傳播，第三方無法竊聽，
• 具有校驗機制，一旦被篡改，通信雙方會立刻發現，
• 配備身份證書，防止身份被冒充，

HTTPS就是在TCP協議層和HTTP協議層中間架起了一層SSL/TSL協議層，這一層能夠把在網路中傳輸的資料進行有效的加密，下面是基于SSL協議的五層網路模型圖：

https支持單向認證（只驗證服務端證書的有效性），也支持雙向驗證（既驗證服務端證書的有效性也驗證客戶端證書的有效性）

SSL/TLS

SSL（Secure Sockets Layer安全套接層），是一種網路安全協議，主要依賴數字證書、非對稱加密、對稱加密、資料完整性校驗以及亂數這5個密碼學的基礎知識，構建出一個完整可信的傳輸鏈，

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

SSL/TLS分為兩層，一層是記錄協議（建立在可靠的傳輸協議上（比如tcp），提供資料封裝，加密解密，資料建議等基本功能），一層是握手協議（建立在記錄協議上，在實際的資料傳輸開始前，進行加密演算法的協商，通信密鑰的交換等），

SSL/TLS發展歷史

• 1994年，NetScape公司設計了SSL協議（Secure Sockets Layer）的1.0版，但是未發布，
• 1995年，NetScape公司發布SSL 2.0版，很快發現有嚴重漏洞，
• 1996年，SSL 3.0版問世，得到大規模應用，
• 1999年，互聯網標準化組織ISOC接替NetScape公司，發布了SSL的升級版TLS 1.0版，
• 2006年和2008年，TLS進行了兩次升級，分別為TLS 1.1版和TLS 1.2版，
• 2011年，ISOC又發布了TLS 1.2的修訂版，

目前，應用最廣泛的是TLS 1.0，接下來是SSL 3.0，但是，主流瀏覽器都已經實作了TLS 1.2的支持，TLS 1.0通常被標示為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3，

基本運行程序

SSL/TLS協議的基本思路是采用公鑰加密法，也就是說，客戶端先向服務器端索要公鑰，然后用公鑰加密資訊并發送給服務器，服務器收到密文后，用自己的私鑰解密，

那么，非對稱加密的引入是否解決了資料傳輸的安全問題？這個問題大家可以思考一下，我們稍后再討論，

另外，細心的人都會發現，非對稱加密機制的安全性，必須建立在公鑰的安全發放這個大前提上，畢竟在大多數情況下，通信雙方并不是面對面的，無法通過安全可靠的物理介質交換公鑰，公鑰本身也是通過網路傳輸的，那么，如何防止公鑰的傳輸程序被攻擊？舉個簡單的例子，A和B為了通信安全，約定使用非對稱加密進行通信，在開始加密通信前，B需要通過網路向A發放自己的公鑰B’和一段密文，但此時C截獲了B‘的發放程序，將自己偽裝成B，并將自己的公鑰C‘和自己的私鑰加密的一段密文發放給了A，A拿到C’后，驗證解密程序成功，就以為自己拿到的確實是B‘，于是開始了加密通信，這樣，A和B都以為自己在和對方通信，但實際上他們其實各自在和C通信，此時C就可以為所欲為，

針對公鑰的安全發放問題，解決辦法就是數字證書，私鑰持有者需要向CA購買數字證書，將公鑰放在數字證書中傳輸，任何第三方只要驗證了數字證書是可信的，就可以相信該證書中的公鑰是可信的，

然而，細心的人可能又有疑問了：數字證書會不會也存在問題，換句話說，如何保證數字證書的有效安全？

數字證書的非法可能有兩種情況：

1. 證書是偽造的：壓根不是CA機構頒發的證書；
2. 證書被篡改過：比如將證書中的公鑰給換了；

數字證書的可靠性，就要靠數字簽名來保證了，關于數字證書和數字簽名的詳細介紹，參考我的另一篇文章《Android簽名機制》-準備知識，這里不再贅述，

解決了證書的安全發放問題后，再回頭看第一個問題：非對稱加密的引入是否解決了資料傳輸的安全問題？

答案是，還不夠！

為什么這么說？因為非對稱加密只能保證資料的傳輸單向安全，所謂非對稱加密，就是一方加密的資訊，只能由另一方解密，雖然私鑰只有自己（服務器）持有，但是公鑰卻是公開的，任何人都可以持有公鑰，那么服務器用私鑰加密過的資訊，任何持有公鑰的人都可以解密出來，換句話說，服務器的資料相當于是在網路上換了種方式裸奔，

※引申思考：既然私鑰加密的資料并沒有隱私性可言，是不是私鑰加密就沒有用處了？

說到這里，你可能會有疑惑：加入了SSL加密層，服務器資料還是在裸奔，還不如直接用HTTP來的省事，

非也非也，單純的非對稱加密確實只能保證資料傳輸的單向安全，然而SSL不僅用了非對稱加密，同時還結合了對稱加密機制，來確保資料傳輸的雙向安全，而這同時也解決了非對稱加密效率過低的弊病，

概括來說，整個簡化的加密通信的流程就是：

1. 客戶端訪問服務器，服務器將自己的證書給到客戶端（瀏覽器）
2. 瀏覽器從證書中拿到服務器的公鑰A
3. 瀏覽器生成一個只有自己知道的對稱密鑰B，用公鑰A加密，并傳給服務器（其實是有協商的程序，這里為了便于理解先簡化）
4. 服務器通過私鑰解密，拿到對稱密鑰B
5. 瀏覽器、服務器之后的資料通信，都用密鑰B進行加密

上述程序的前4步，又稱為“握手階段”，

SSL/TLS握手階段的詳細程序

1.客戶端發出請求（ClientHello）

首先，客戶端（通常是瀏覽器）先向服務器發出加密通信的請求，這被叫做ClientHello請求，

在這一步，客戶端主要向服務器提供以下資訊：

• 支持的協議版本，比如TLS 1.0版，
• 一個客戶端生成的亂數A，稍后用于生成"對話密鑰"，
• 支持的加密方法，比如RSA公鑰加密，
• 支持的壓縮方法，

2.服務器回應（SeverHello）

服務器收到客戶端請求后，向客戶端發出回應，這叫做SeverHello，

服務器的回應包含以下內容：

• 確認使用的加密通信協議版本，比如TLS 1.0版本，如果瀏覽器與服務器支持的版本不一致，服務器關閉加密通信，
• 一個服務器生成的亂數B，稍后用于生成"對話密鑰"，
• 確認使用的加密方法，比如RSA公鑰加密，
• 服務器證書，

除此之外，如果服務器需要使用雙向認證，就會再包含一項請求，要求客戶端提供"客戶端證書"，比如，金融機構往往只允許認證客戶連入自己的網路，就會向正式客戶提供USB密鑰，里面就包含了一張客戶端證書，

3.客戶端回應

客戶端收到服務器回應以后，首先驗證服務器證書，如果證書不是可信機構頒布、或者證書中的域名與實際域名不一致、或者證書已經過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續通信，

如果證書沒有問題，客戶端就會從證書中取出服務器的公鑰，然后，向服務器發送下面三項資訊，

• 一個亂數C，該亂數用服務器公鑰加密，防止被竊聽，
• 編碼改變通知，表示隨后的資訊都將用雙方商定的加密方法和密鑰發送，
• 客戶端握手結束通知，表示客戶端的握手階段已經結束，這一項同時也是前面發送的所有內容的hash值，用來供服務器校驗，

上面的亂數C，是整個握手階段出現的第三個亂數，又稱"pre-master key"，有了它以后，客戶端和服務器就同時有了三個亂數，接著雙方就用事先商定的加密方法，各自生成本次會話所用的同一把"會話密鑰"，

此外，如果前一步，服務器要求客戶端證書，客戶端會在這一步發送證書及相關資訊，

4.服務器的最后回應

服務器收到客戶端的第三個亂數pre-master key之后，計算生成本次會話所用的"會話密鑰"（對稱密鑰），然后，向客戶端最后發送下面資訊，
（1）編碼改變通知，表示隨后的資訊都將用雙方商定的加密方法和密鑰發送，
（2）服務器握手結束通知，表示服務器的握手階段已經結束，這一項同時也是前面發送的所有內容的hash值，用來供客戶端校驗，

至此，整個握手階段全部結束，接下來，客戶端與服務器進入加密通信，就完全是使用普通的HTTP協議，只不過用"會話密鑰"加密內容，

為什么是三個亂數？

整個握手階段為什么要用三個亂數來生成“會話密鑰”，網友 Bomb250 的解釋很好：

“不管是客戶端還是服務器，都需要亂數，這樣生成的密鑰才不會每次都一樣，由于SSL協議中證書是靜態的，因此十分有必要引入一種隨機因素來保證協商出來的密鑰的隨機性，

對于RSA密鑰交換演算法來說，pre-master-key本身就是一個亂數，再加上hello訊息中的隨機，三個亂數通過一個密鑰匯出器最侄訓出一個對稱密鑰，

pre master的存在在于SSL協議不信任每個主機都能產生完全隨機的亂數，如果亂數不隨機，那么pre master secret就有可能被猜出來，那么僅使用pre master secret作為密鑰就不合適了，因此必須引入新的隨機因素，那么客戶端和服務器加上pre master secret三個亂數一同生成的密鑰就不容易被猜出了，一個偽隨機可能完全不隨機，但是三個偽隨機就十分接近隨機了，每增加一個自由度，隨機性增加的可不是一，”

為什么更加安全的HTTPS沒有在互聯網中全面應用

• SSL 證書需要錢，功能越強大的證書費用越高，個人網站、小網站沒有必要一般不會用，
• SSL 證書通常需要系結 IP，不能在同一 IP 上系結多個域名，IPv4 資源不可能支撐這個消耗，（ SSL 有擴展可以部分解決這個問題，但是比較麻煩，而且要求瀏覽器、作業系統支持，Windows XP 就不支持這個擴展，考慮到 XP 的裝機量，這個特性幾乎沒用，）
• HTTPS 連接快取不如 HTTP 高效，大流量網站如非必要也不會采用，流量成本太高，
• HTTPS 連接服務器端資源占用高很多，支持訪客稍多的網站需要投入更大的成本，如果全部采用 HTTPS，基于大部分計算資源閑置的假設的 VPS 的平均成本會上去，
• HTTPS 協議握手階段比較費時，對網站的回應速度有負面影響，如非必要，沒有理由犧牲用戶體驗，
• 最關鍵的，SSL 證書的信用鏈體系并不安全，特別是在某些國家（咳咳，你們懂的）可以控制CA 根證書的情況下，中間人攻擊一樣可行，
• 對于大型網站來說，換成SSL要保證跟你合作的所有服務都支持SSL，服務器設定也會更麻煩，

Stackoverflow 的創始人也曾經針對為什么Stackoverflow不使用https做出了回答：Stackoverflow.com: the road to SSL ? Nick Craver

中間人攻擊

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

1.SSL證書欺騙攻擊

此類攻擊較為簡單常見，首先通過ARP欺騙、DNS劫持甚至網關劫持等等，將客戶端的訪問重定向到攻擊者的機器，讓客戶端機器與攻擊者機器建立HTTPS連接（使用偽造證書），而攻擊者機器再跟服務端連接，這樣用戶在客戶端看到的是相同域名的網站，但瀏覽器會提示證書不可信，用戶不點擊“繼續瀏覽”就能避免被劫持，所以這是最簡單的攻擊方式，也是最容易識別的攻擊方式，

2.SSL剝離攻擊

SSL剝離，即將HTTPS連接降級到HTTP連接，假如客戶端直接訪問HTTPS的URL，攻擊者是沒辦法直接進行降級的，因為HTTPS與HTTP雖然都是TCP連接，但HTTPS在傳輸HTTP資料之前，需要進行SSL握手，并協商對稱密鑰用于后續的加密傳輸；假如客戶端與攻擊者進行SSL握手，而攻擊者無法提供可信任的證書來讓客戶端驗證通過進行連接，所以客戶端的系統會判斷為SSL握手失敗，斷開連接，

該攻擊方式主要是利用用戶并不會每次都直接在瀏覽器上輸入https://xxx.xxx.com來訪問網站，或者有些網站并非全網HTTPS，而是只在需要進行敏感資料傳輸時才使用HTTPS的漏洞，中間人攻擊者在劫持了客戶端與服務端的HTTP會話后，將HTTP頁面里面所有的https://超鏈接都換成http://，用戶在點擊相應的鏈接時，是使用HTTP協議來進行訪問；這樣，就算服務器對相應的URL只支持HTTPS鏈接，但中間人一樣可以和服務建立HTTPS連接之后，將資料使用HTTP協議轉發給客戶端，實作會話劫持，

這種攻擊手段更讓人難以提防，因為它使用HTTP，不會讓瀏覽器出現HTTPS證書不可信的警告，而且用戶很少會去看瀏覽器上的URL是https://還是http://，特別是App的WebView中，應用一般會把URL隱藏掉，用戶根本無法直接查看到URL出現例外，

老和尚和小和尚的故事

作者：牟旭東

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

來源：知乎

著作權歸作者所有，商業轉載請聯系作者獲得授權，非商業轉載請注明出處，

下面開始講一個無聊的故事，和問題關系不大，時間緊張的看官可以到此為止了，

從前山上有座廟，廟里有個和尚…，別胡鬧了，老和尚來了，

小和尚問老和尚：ssl為什么會讓http安全？

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

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

小和尚問到：那師傅何解？

老和尚：我和小花只要知道每封信的密碼，就可以讀到對方加密的信件，關鍵是我們互相之間怎么知道這個對稱密碼，你說，我要是將密碼寫封信給她，信被別人偷了，那大家不都知道我們的密碼了，也就能夠讀懂我們情書了，不過還是有解的，這里我用到了江湖中秘傳的非對稱密碼，我現在手頭有兩個密碼，一個叫“公鑰”，一個叫“私鑰”，公鑰發布到了江湖上，好多人都知道，私鑰嘛，江湖上只有我一個人知道；這兩個密鑰有數學相關性，就是說用公鑰加密的信件，可以用私鑰解開，但是用公鑰卻解不開，公鑰小花是知道的，她每次給我寫信，都要我的公鑰加密她的對稱密碼，單獨寫一張密碼紙，然后用她的對稱密碼加密她的信件，這樣我用我的私鑰可以解出這個對稱密碼，再用這個對稱密碼來解密她的信件，

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

小和尚問：那然后呢？

老和尚：從嵩山少林寺回山上寺廟時，我將有火印的公鑰親自給小花送去，可是之后再也沒有收到小花的來信，過了一年才知道，其實小花還是給我寫過信的，當時信確實是用有火印的公鑰加密，張屠夫拿到信后，由于不知道我的私鑰，解不開小花的密碼信，所以一怒之下將信件全部啥訓了，也由于張屠夫無法知道小花的對稱密碼而無法回信，小花發出幾封信后石沉大海，也心生疑惑，到處打聽我的近況，這下張屠夫急了，他使用我發布的公鑰，仿照小花的語氣，給我發來一封信，拿到信時我就覺得奇怪，信紙上怎么有一股豬油的味道，結尾竟然還關切的詢問我的私鑰，情知有詐，我思量無論如何要找到辦法讓我知道來的信是否真是小花所寫，后來竟然讓我想到了辦法…

老和尚摸著光頭說：這頭發可不是白掉的，我托香客給小花帶話，我一切安好，希望她也擁有屬于自己的一段幸福，不對，是一對非對稱密鑰，小花委托小鎮美女協會給小花公鑰打上火印后，托香客給我送來，這樣小花在每次給我寫信時，都會在密碼紙上貼上一朵小牡丹，牡丹上寫上用她自己的私鑰加密過的給我的留言，這樣我收到自稱是小花的信后，我會先抽出密碼紙，取下小牡丹，使用小花的公鑰解密這段留言，如果解不出來，我會直接將整封信連同密碼紙一起扔掉，因為這封信一定不是小花寫的，如果能夠解出來，這封信才能確信來之于小花，我才仔細的解碼閱讀，

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