新人向-從零開始設(shè)計一個安全的通信協(xié)議
網(wǎng)絡(luò)上有大量關(guān)于 HTTPS 的技術(shù)文章，但是大部分文章都在以“英譯漢”的方式，把 TLS 的握手流程講出來。
本文將嘗試從“如何實現(xiàn)”的角度，通過從零開始設(shè)計一個安全的通信協(xié)議的方式，幫助讀者加快對信息安全的理解。
本文內(nèi)容和 TLS 的設(shè)計思想基本一致，但是某些細節(jié)可能略有不同。
鑒于網(wǎng)絡(luò)上的文章質(zhì)量參差不齊，建議有興趣的讀者通過閱讀官方文檔 rfc5246 的方式了解 TLS 的詳細設(shè)計。
http 面臨的問題
HTTP 面臨的三個安全問題分別是：eavesdropping（竊聽）,tampering（篡改）,message forgery（信息偽造）。
瀏覽器和服務(wù)器進行信息傳遞時，會通過第三方轉(zhuǎn)發(fā)信息。
此時，信息安全面臨三個問題：
- 信息內(nèi)容會被第三方知道=》竊聽
- 第三方可以修改信息的內(nèi)容=》篡改
- 第三方可以丟棄服務(wù)器的信息，并假裝服務(wù)器返回虛假的信息=》信息偽造
0x1 通過簽名解決信息偽造和篡改
為了防止第三方偽造信息，我們很容易的想到通過 簽名 的方式。
講解簽名之前，我們需要先對非對稱加密方式以及消息摘要：（Digital Digest）有所了解。
對稱加密是通過同一份密鑰加密和解密數(shù)據(jù)，而非對稱加密則有兩份密鑰，分別是公鑰和私鑰，用公鑰加密的數(shù)據(jù)，要用私鑰才能解密，用私鑰加密的數(shù)據(jù)，要用公鑰才能解密。
常用的非對稱加密方式有:RSA、ECC。
具體的原理，這里不進行展開。我們只需要了解用于簽名的非對稱加密需要滿足的兩個特性即可：
公鑰非常短：降低客戶端加密的計算量
私鑰非常長：防止第三方偽造或篡改，防止服務(wù)器抵賴。
非對稱加密通常對等待加密的信息長度有要求，所以，我們一般只對消息摘要加密。
消息摘要：（Digital Digest）又稱為指紋（Finger Print）。可以通過單向哈希(one-way hash)函數(shù)，為不定長度的信息生成一個固定長度的摘要。
通信安全的第一個要求：服務(wù)器的私鑰要保證安全
通信安全的第二個要求：安全可靠的非對稱加密方式。比如 2048位的RSA加密
通信安全的第三個要求：安全可靠的摘要算法，如果摘要算法的沖突非常多，則很容易被第三方攻擊
有了以上知識，我們來看一下數(shù)字簽名是如何進行的？
簽名：
通對某一份數(shù)據(jù)進行單向哈希，縮短等待加密信息的長度=》單項哈希
通過私鑰對信息摘要進行加密運算并生成簽名，表示我認可了這份數(shù)據(jù)（只有我擁有私鑰，第三方難以偽造）=》簽名
驗簽：
通過公鑰解析簽名
對數(shù)據(jù)進行單向哈希
判等
我們可以模擬一下會話的握手階段的通信流程：
瀏覽器：hello
服務(wù)器：服務(wù)器公鑰 + encrypt(服務(wù)器公鑰，服務(wù)器私鑰)
瀏覽器：encrypt(hash(信息)，服務(wù)器公鑰) + 信息
服務(wù)器：encrypt(hash(信息)，服務(wù)器私鑰) + 信息
上面的通信方式是不是安全多了？
且慢，如果服務(wù)器返回公鑰時，被第三方攔截，然后替換為第三方的公鑰，我們該如何怎么辦？
考慮到把所有網(wǎng)站的公鑰提前存儲到瀏覽器中并不現(xiàn)實（數(shù)量巨大，并且新增公鑰、撤銷公鑰都極為不便）。我們可以提前瀏覽器內(nèi)置一份或多份公鑰（根證書），然后再把流程升級一下：
會話的握手階段的通信流程：
瀏覽器：hello
服務(wù)器：服務(wù)器公鑰 + encrypt(服務(wù)器公鑰，第三方私鑰)
瀏覽器：encrypt(hash(信息)，服務(wù)器公鑰) + 信息
服務(wù)器：encrypt(hash(信息)，服務(wù)器私鑰) + 信息
實際上，瀏覽器會通過一條證書鏈驗證服務(wù)器的公鑰是否安全
通信安全的第四個要求：不要隨意添加根證書。比如，為了安裝一些軟件or游戲，為了訪問某些網(wǎng)站
但是，簽名在解決信息偽造和篡改的同時又引入了另外一個問題：性能消耗。
雖然只需要對摘要信息進行簽名，但是，它依然給服務(wù)器帶來了非常巨大的運算壓力。
一般情況下，簽名操作會導(dǎo)致服務(wù)器的處理速度變?yōu)樵瓉淼娜f分之一甚至更低（根據(jù)算法的不同，實際情況可能會有數(shù)量級的變化）。
并且，它還面臨一個非常巨大安全問題：竊聽。第三方仍然可以看到通信內(nèi)容。
0x2 引入對稱加密算法降低性能消耗并解決竊聽問題
既然非對稱加密對性能影響巨大，剩下的唯一方案是對稱加密。
因為服務(wù)器需要和數(shù)量眾多的瀏覽器進行通信，所以，每條通信用到的對稱加密密鑰都應(yīng)該是不同的。否則，瀏覽器和服務(wù)器之間的通信依然會被第三方解密。
引入對稱加密后，就可以再次升級通信流程：
會話的握手階段的通信流程：
瀏覽器：hello
服務(wù)器：服務(wù)器公鑰 + encrypt(服務(wù)器公鑰，第三方私鑰) + 第一個隨機數(shù)
瀏覽器：encrypt(第二個隨機數(shù)，服務(wù)器公鑰)
雙方根據(jù)PRF算法生成一個對稱加密的密鑰并用于之后的通信：
瀏覽器：encrypt(hash(信息)，對稱密鑰) +encrypt(信息，對稱密鑰)
服務(wù)器：encrypt(hash(信息)，對稱密鑰) +encrypt(信息，對稱密鑰)
Master_key = PRF(premaster_secret, “master secrect”, 隨機數(shù)1+隨機數(shù)2)其中 PRF 是一個隨機函數(shù)，定義如下：PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed)
這種雙方各自生成一個隨機數(shù)的方式可以應(yīng)對瀏覽器或者服務(wù)器單方面出現(xiàn)漏洞（隨機數(shù)不隨機）的情況。
與此同時，在一次會話的建立中，服務(wù)器只需要解析一次就可以完成整個會話。
安全通信的第四個要求：安全可靠的隨機數(shù)生成器
實踐中，TLS 要求，“瀏覽器在發(fā)起 hello 請求時，發(fā)送另外一個隨機數(shù)來增加隨機性"
安全故事:1996年，研究人員就發(fā)現(xiàn)了網(wǎng)景瀏覽器1.1的偽隨機數(shù)發(fā)生器僅僅利用了三個參數(shù)：當天的時間，進程ID和父進程ID。在1996年，利用當時的機器僅需要25秒鐘的時間就可以破解一個SSL通信
