SSL/TLS的原理以及互聯網到底是如何工做的（3）—TLS的專場

我：hi，TLS！此次是你的專場哦！

TLS：OK，那我就開始了！首先，個人大名叫作Transport Layer Security Protocol（傳輸層安全協議），是SSL的升級版。實際上個人左手和右手都是能用的，左手叫Record Layer（記錄層），右手叫Handshake Layer（握手層）......

我：喂喂，等一下，記錄層？握手層？這都是什麼啊？

TLS：別打斷我！聽我慢慢解釋：TLS是基於TCP的可靠鏈接，而想要創建一個可靠鏈接就必須有一個被稱爲握手的過程，TCP就有啊（TCP：沒錯，我創建鏈接時就要經歷three-way handshake（三路握手）的，這具體過程是......）

我&TLS：STOP！TCP，有空會給你開個專場的，如今你先暫時回去工做吧！（TCP：OK，說定了哦！）

TLS：繼續吧，TCP有握手過程，那麼我也同樣，你也能夠把個人握手過程當作是在TCP握手過程基礎之上的改進。
開始說具體過程了！

首先，客戶端向服務器端發送一個message，名叫"client hello"，包括SSL/TLS協議的版本號，客戶端生成的隨機數（P1，P指Parameter，參數）以及客戶端支持的加密算法；

而後，服務器端發送另外一個message，名叫"server hello"，確認所使用的加密算法以及生成併發送另外一個隨機數（P2），特別注意還有服務器端的數字證書[呢......

我：等一下，數字證書？爲何會這麼早就出現了？

TLS：我說，你是怎麼想的？難道你認爲要鏈接創建開始傳輸用戶數據以後才進行基於數字證書的身份認證嗎？

我：爲何不行呢？先完成握手，創建鏈接，而後立刻進行身份認證，彷佛也不晚呢......

TLS：你！真！是！個！大！笨！蛋！鏈接創建以後首先必定是客戶端數據被髮送過去的，在瀏覽網頁的狀況下就是GET請求的HTTP數據包，若是不在此以前進行身份認證，那麼這個數據包極可能會落到冒充目標網站服務器的第三方手裏（也就是所謂的中間人攻擊）！而你尚未任何辦法！

我：就一個GET數據包，好像也不會怎麼樣......

TLS：I 服了 YOU！你知道網站的自動登陸功能是怎麼實現的嗎？是cookie的功勞！第一次登錄成功以後你的用戶名和密碼就被儲存在了cookie裏，再次登陸時瀏覽器就會在一開始的GET數據包中加入這個cookie，準確來講是加入數據包頭部（HTTP Headers），cookie自己就是一種特殊的HTTP headers！在一開始用戶名和密碼就發過去了，那麼傳回來的就是登陸以後的界面了，這就是自動登陸的奧祕！

我：啊，我明白了！若是是啓用了自動登陸的網站被中間人攻擊了，那麼一旦不能在第一個用戶數據包被傳輸以前發現這一點，那麼用戶帳戶就直接落到第三方手裏了！先不說cookie的加密根本就不強，其實第三方都不須要破解加密的，只要直接利用手裏的cookie就能完成登陸從而隨心所欲了！

TLS：沒錯，就是這樣！因此身份認證過程必定要在握手階段就完成！
接着說吧：
身份認證能夠是雙向的，也就是說服務器端也能夠向客戶端請求證書，認證過程也是相似的，簡單來講就是對比簽名和私鑰還有主機名等，通常狀況下這個匹配過程是很嚴格的，第三方的僞造證書很難過關。順便說一句，身份認證時使用的算法和最終加密時使用的算法不少時候是同一個。對於瀏覽器，他本身信任着和不信任着一套證書，IE和chrome依據操做系統自帶的證書系統，firefox則有着本身的一套證書系統。這些證書都是由可信賴的第三方證書頒發機構（Certficate Authority）頒發的，通常狀況下沒問題，除了一個大流氓以外......

我：哪一個大流氓？啊，想起來了，之前好像聽你說過，CNNIC（中國互聯網信息中心），不過究竟是怎麼回事啊？

TLS：此次我沒空解釋，下次我在說明中間人攻擊的具體過程時就會好好說明的。先繼續吧：
身份認證沒有問題以後，客戶端就會再生成一個隨機數（P3），並用數字證書上的公鑰進行加密以後再傳輸給服務器端。這裏採用的是非對稱加密算法，就以G+爲例吧：」並使用ECDHE_ECDSA做爲密鑰交換機制「，這個ECDHE_ECDSA就是一種公鑰算法（又叫作非對稱算法），加密公鑰是公開的，解密私鑰是祕密的，因此第三方沒法得知P3的值。服務器端收到以後就用本身的私鑰解密獲得P3，而後發送message通知客戶端本身收到了。

接下來，服務器和客戶端根據約定的加密算法，同時用手中的P1,P2和P3算出祕密的session key（會話金鑰），通常狀況下是128位或者256位，而後客戶端再用這個金鑰加密之後全部須要傳輸的用戶數據再進行傳輸。這裏有必要提一下，此時的傳輸單元被稱做socket（套接字），應用層協議（如HTTP）先處理好數據，再被徹底加密（包括頭部），再被注入到套接字中，這些套接字除了源地址和目的地址還有必要的完整性驗證機制以及其餘保證可靠性所須要的數據以外其餘一切都是被強加密的。SSL（Secure Socket Layer，安全套接字層）的名字也是這麼來的。

以上就是握手的全過程，握手層完成握手以後就是記錄層在TCP的幫助之下負責傳輸了，請注意握手時採用的密鑰交換算法和傳輸時採用的數據加密算法不是同一個，傳輸時的數據加密算法是對稱加密算法，密鑰就是經過握手最終算出來的那個會話金鑰，以G+爲例，這個算法就是CHACHA20_POLY1305。

我：（頭昏眼花）真的很複雜啊......

TLS：暈死，你看到那份100多頁的RFC（Request For Comment，請求評價文檔）大概會跳樓吧！算了，直接上圖吧！