標籤：ssltls tcpip 三向交握 電腦網路通訊協定
我：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資料包，好像也不會怎麼樣......
T
LS：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，請求評價文檔）大概會跳樓吧！算了，直接吧！
我：謝謝啊（笑）。
SSL/TLS的原理以及互連網究竟是如何工作的（3）—TLS的專場
