密鑰交換簡單的說就是利用非對稱加密算法來加密對稱密鑰保證傳輸的安全性，之後用對稱密鑰來加密數據。
★方案1——單純用“對稱加密算法”的可行性
首先簡單闡述一下，“單純用對稱加密”爲啥是【不可行】滴。
如果“單純用對稱加密”，瀏覽器和網站之間勢必先要交換“對稱加密的密鑰”。
如果這個密鑰直接用【明文】傳輸，很容易就會被第三方（有可能是“攻擊者”）偷窺到；如果這個密鑰用密文傳輸，那就再次引入了“如何交換加密密鑰”的問題——這就變成“先有雞還是先有蛋”的循環邏輯了。
所以，【單純用】對稱加密，是沒戲滴。
★方案2——單純用“非對稱加密算法”的風險
說完“對稱加密”，再來說說“非對稱加密”。
在前面的“背景知識”中，已經大致介紹過“非對稱加密”的特點——“加密和解密採用不同的密鑰”。基於這個特點，可以避開前面提到的“循環邏輯”的困境。大致的步驟如下：
第1步
網站服務器先基於“非對稱加密算法”，隨機生成一個“密鑰對”（爲敘述方便，稱之爲“k1 和 k2”）。因爲是隨機生成的，目前爲止，只有網站服務器才知道 k1 和 k2。
第2步
網站把 k1 【私鑰】保留在自己手中，把 k2【公鑰】 用【明文】的方式發送給訪問者的瀏覽器。
因爲 k2 是明文發送的，自然有可能被偷窺。不過不要緊。即使偷窺者拿到 k2，也【很難】根據 k2 推算出 k1
（這一點是由“非對稱加密算法”從數學上保證的）。
第3步
瀏覽器拿到 k2 之後，先【隨機生成】第三個對稱加密的密鑰（簡稱 k）。
然後用 k2 加密 k，得到 k'【pre-master key】（k' 是 k 的加密結果）
瀏覽器把 k' 發送給網站服務器。
由於 k1 和 k2 是成對的，所以只有 k1 才能解密 k2 的加密結果。
因此這個過程中，即使被第三方偷窺，第三方也【無法】從 k' 解密得到 k
第4步
網站服務器拿到 k' 之後，用 k1 進行解密，得到 k
至此，瀏覽器和網站服務器就完成了密鑰交換，雙方都知道 k，而且【貌似】第三方無法拿到 k
然後，雙方就可以用 k 來進行數據雙向傳輸的加密。
現在，給大夥兒留一個思考時間——你覺得上述過程是否嚴密？如果不嚴密，漏洞在哪裏？
OK，現在俺來揭曉答案。 “方案2”依然是不安全滴 ——雖然“方案2”可以在一定程度上防止網絡數據的【偷窺/嗅探】，但是【無法】防範網絡數據的【篡改】。
假設有一個攻擊者處於“瀏覽器”和“網站服務器”的通訊線路之間，並且這個攻擊者具備“修改雙方傳輸數據”的能力。那麼，這個攻擊者就可以攻破“方案2”。具體的攻擊過程如下：
第1步
這一步跟原先一樣——服務器先隨機生成一個“非對稱的密鑰對”k1 和 k2（此時只有網站知道 k1 和 k2）
第2步
當網站發送 k2 給瀏覽器的時候，攻擊者截獲 k2，保留在自己手上。
然後攻擊者自己生成一個【僞造的】密鑰對（以下稱爲 pk1 和 pk2）。
攻擊者把 pk2 發送給瀏覽器。
第3步
瀏覽器收到 pk2，以爲 pk2 就是網站發送的。
瀏覽器不知情，依舊隨機生成一個對稱加密的密鑰 k，然後用 pk2 加密 k，得到密文的 k'
瀏覽器把 k' 發送給網站。
（以下是關鍵）
發送的過程中，再次被攻擊者截獲。
因爲 pk1 pk2 都是攻擊者自己生成的，所以攻擊者自然就可以用 pk1 來解密 k' 得到 k
然後，攻擊者拿到 k 之後，用之前截獲的 k2 重新加密，得到 k''，並把 k'' 發送給網站。
第4步
網站服務器收到了 k'' 之後，用自己保存的 k1 可以正常解密，所以網站方面不會起疑心。
至此，攻擊者完成了一次漂亮的偷樑換柱，而且讓雙方都沒有起疑心。
上述過程，也就是傳說中大名鼎鼎的“中間人攻擊” 。洋文叫做“Man-In-The-Middle attack”。縮寫是 MITM。
“中間人攻擊”有很多種“類型”，剛纔演示的是針對“【單純的】非對稱加密”的中間人攻擊。至於“中間人攻擊”的其它類型，俺在本系列的後續博文中，還會再提到。
爲了更加形象，補充兩張示意圖，分別對應“偷窺模式”和“中間人模式”。讓你更直觀地體會兩者的差異。
★方案2失敗的根源——缺乏【可靠的】身份認證
爲啥“方案2”會失敗？
除了俺在圖中提到的“攻擊者具備篡改數據的能力”，還有另一點關鍵點——“方案2缺乏身份認證機制”。
正是因爲“缺乏身份認證機制”，所以當攻擊者一開始截獲 k2 並把自己僞造的 pk2 發送給瀏覽器時，瀏覽器無法鑑別：自己收到的密鑰是不是真的來自於網站服務器。
假如具備某種【可靠的】身份認證機制，即使攻擊者能夠篡改數據，但是篡改之後的數據很容易被識破。那篡改也就失去了意義。
★身份認證的幾種方式
下面，俺來介紹幾種常見的“身份認證原理”。
◇基於某些“私密的共享信息”
爲了解釋“私密的共享信息”這個概念，咱們先拋開“信息安全”，談談日常生活中的某個場景。
假設你有一個久未聯繫的老朋友。因爲時間久遠，你已經沒有此人的聯繫方式了。某天，此人突然給你發了一封電子郵件。
那麼，你如何確保——發郵件的人確實是你的老朋友捏？
有一個辦法就是：你用郵件向對方詢問某個私密的事情（這個事情只有你和你的這個朋友知道，其他人不知道）。如果對方能夠回答出來，那麼對方【很有可能】確實是你的老朋友。
從這個例子可以看出，如果通訊雙方具有某些“私密的共享信息”（只有雙方知道，第三方不知道），就能以此爲基礎，進行身份認證，從而建立信任。
◇基於雙方都信任的“公證人”
“私密的共享信息”，通常需要雙方互相比較熟悉，才行得通。如果雙方本來就互不相識，如何進行身份認證以建立信任關係捏？
這時候還有另一個辦法——依靠雙方都信任的某個“公證人”來建立信任關係。
如今 C2C 模式的電子商務，其實用的就是這種方式——由電商平臺充當公證人，讓買家與賣家建立某種程度的信任關係。
考慮到如今的網購已經相當普及，大夥兒應該對這類模式很熟悉吧。所以俺就不浪費口水了。
★如何解決 SSL 的身份認證問題——CA 的引入
說完身份認證的方式/原理，再回到 SSL/TLS 的話題上。
對於 SSL/TLS 的應用場景，由於雙方（“瀏覽器”和“網站服務器”）通常都是互不相識的，顯然不可能採用第一種方式（私密的共享信息），而只能採用第二種方式（依賴雙方都信任的“公證人”）。
那麼，誰來充當這個公證人捏？這時候，CA 就華麗地登場啦。
所謂的 CA，就是“數字證書認證機構”的縮寫，洋文全稱叫做“Certificate Authority”。關於 CA 以及 CA 頒發的“CA 證書”，俺已經寫過一篇教程：《 數字證書及CA的掃盲介紹 》，介紹其基本概念和功能。所以，此處就不再重複嘮叨了。
如果你看完那篇 CA 的掃盲，你自然就明白——CA 完全有資格和能力，充當這個“公證人”的角色。
★方案3——基於 CA 證書進行密鑰交換
其 實“方案3”跟“方案2”很像的，主要差別在於——“方案3”增加了“CA 數字證書”這個環節。所謂的數字證書，技術上依賴的還是前面提到的“非對稱加密”。爲了描述“CA 證書”在 SSL/TLS 中的作用，俺大致說一下原理（僅僅是原理，具體的技術實現要略複雜些）：
第1步（這是“一次性”的準備工作）
網站方面首先要花一筆銀子，在某個 CA 那裏購買一個數字證書。
該證書通常會對應幾個文件：其中一個文件包含公鑰，還有一個文件包含私鑰。
此處的“私鑰”，相當於“方案2”裏面的 k1；而“公鑰”類似於“方案2”裏面的 k2。
網站方面必須在 Web 服務器上部署這兩個文件。
所謂的“公鑰”，顧名思義就是可以公開的 key；而所謂的“私鑰”就是私密的 key。
其實前面已經說過了，這裏再嘮叨一下：
“非對稱加密算法”從數學上確保了——即使你知道某個公鑰，也很難（不是不可能，是很難）根據此公鑰推導出對應的私鑰。
第2步
當瀏覽器訪問該網站，Web 服務器首先把公鑰發送給瀏覽器。
第3步
瀏覽器驗證網站發過來的證書。如果發現其中有詐，瀏覽器會提示“CA 證書安全警告”。
由於有了這一步，就大大降低了（注意：是“大大降低”，而不是“徹底消除”）前面提到的“中間人攻擊”的風險。
爲啥瀏覽器能發現 CA 證書是否有詐？
因爲正經的 CA 證書，都是來自某個權威的 CA。如果某個 CA 足夠權威，那麼主流的操作系統（或瀏覽器）會內置該 CA 的“根證書”。
（比如 Windows 中就內置了幾十個權威 CA 的根證書）
因此，瀏覽器就可以利用系統內置的根證書，來判斷網站發過來的 CA 證書是不是某個 CA 頒發的。
（關於“根證書”和“證書信任鏈”的概念，請參見之前的教程《 數字證書及CA的掃盲介紹 》）
第4步
如果網站發過來的 CA 證書沒有問題，那麼瀏覽器就從該 CA 證書中提取出“公鑰”。
然後瀏覽器隨機生成一個“對稱加密的密鑰”（以下稱爲 k）。用 CA 證書的公鑰加密 k，得到密文 k'
瀏覽器把 k' 發送給網站。
第5步
網站收到瀏覽器發過來的 k'，用服務器上的私鑰進行解密，得到 k。
至此，瀏覽器和網站都擁有 k，“密鑰交換”大功告成啦。
★關於“客戶端證書”
前面介紹的“方案3”僅僅使用了“服務端證書”——通過服務端證書來確保服務器不是假冒的。
除了“服務端證書”，在某些場合中還會涉及到“客戶端證書”。所謂的“客戶端證書”就是用來證明客戶端（瀏覽器端）訪問者的身份。
比如在某些金融公司的內網，你的電腦上必須部署“客戶端證書”，才能打開重要服務器的頁面。
由於本文主要介紹的是【公網】上的場景，這種場景下大都【不需要】“客戶端證書”。所以，對“客戶端證書”這個話題，俺就偷個懶，略過不提。
★結尾
可能有同學會問：那麼“方案3”是否就足夠嚴密，無懈可擊了捏？
俺只能說，“方案3”【從理論上講】沒有明顯的漏洞。目前的 SSL/TLS 大致採用的就是這個方案。
但 是，“理論”一旦落實到“實踐”，往往是有差距滴，會引出新的問題。套用某 IT 大牛的名言，就是： In theory, there is no difference between theory and practice. But in practice, there is.
所以在本系列的後續博文，俺還會再來介紹“針對 SSL/TLS 的種種攻擊方式”以及“對應的防範措施”。