首先來看一種場景：小紅髮信息約小明放學後去電影。
正常的信息流動是這樣的：
1.小紅 -> 放學後去看電影吧？ -> 小明
2.小明 -> 好，校門口等我。 -> 小紅
但如果存在一箇中間人把小紅和小明的信息攔截，並做了修改，信息流變成了下面這樣：
1.小紅 -> 放學後去看電影吧？-> 中間人（你） -> 今天上課有點累，放學我就回家了，不要等我。 -> 小明
2.小明 -> 好吧，好好休息。 -> 中間人（你） -> 不去了，放學後我就回家。 -> 小明
小紅以爲小明不陪自己看電影，小明以爲小紅放學就回家了，而你就找了個理由約上小紅去看電影了。
之所以會產生誤解，是因爲小紅和小明沒辦法驗證對方信息的真假，都以爲收到了對方的正確信息，這是個典型的中間人攻擊的例子。
HTTPS正是要解決這個問題，在HTTP傳輸層之上加了一個安全層（SSL或TLS協議實現），可以做到以下3點：
- **數據的保密性 **
- 校驗雙方身份的真實性
- 數據的完整性
下面來看https是如果解決這3個問題的。
一、數據的保密性
數據要保密，就需要對數據進行加密。加密算法可以分爲2類，一類是對稱加密算法，另一類是非對稱加密算法。
對稱加密算法，加密和解密使用相同的密鑰，優點是加密速度快，缺點是如果密鑰泄露的話就無法做到保密了。常見的對稱加密算法有DES、AES等。
非對稱加密算法，又叫公開密鑰加密。需要有2個密鑰，公鑰和私鑰，公鑰向所有人公開，私鑰不公開。用公鑰加密的數據只有私鑰才能解密；反之，用私鑰加密的數據只有公鑰才能解密。因爲這種特性，非對稱加密算法可以用來校驗數字簽名，下面會具體講解。
很顯然，僅使用對稱加密算法是不現實的，互聯網中通信的雙方大多是臨時建立的連接，不可能提前協商好密鑰，而且密鑰也要進行傳輸，無法保證密鑰本身的安全性。
如果使用非對稱加密，客戶端向服務器發送數據是安全的，客戶端用服務器的公鑰進行加密，只有服務器用自己的私鑰才能解密。但如果服務器用私鑰對數據進行加密，則所有人都可以用公鑰進行解密，這是不安全的。
HTTPS的解決方案是這樣的：用非對稱算法隨機加密出一個對稱密鑰，然後雙方用對稱密鑰進行通信。具體來說，就是客戶端生成一個隨機密鑰，用服務器的公鑰對這個密鑰進行非對稱加密，服務器用私鑰進行解密，然後雙方就用這個對稱密鑰來進行數據加密了。
二、校驗雙方身份的真實性
上面說了加密，保證了數據不能被他人讀取，但通信的雙方怎樣校驗對方的身份呢？HTTPS使用了數字證書，數字證書就是身份認證機構（Certificate Authority）蓋在數字身份證上的一個章或印（或者說加在數字身份證上的一個簽名），這一行爲表示身份認證機構已認定這個人。證書的合法性可以向CA驗證。
數字證書主要包含以下信息：
- 證書頒發機構
- 證書頒發機構簽名
- 證書綁定的服務器域名
- 證書版本、有效期
- 簽名使用的加密算法（非對稱算法，如RSA）
- 公鑰
客戶端收到服務器的響應後，先向CA驗證證書的合法性（根據證書的簽名、綁定的域名等信息），如果校驗不通過，瀏覽器會中止連接，向用戶提示證書不安全。
需要提一點的是，證書的製作方法是公開的，任何人都可以自己製作證書，所以有些公司不向CA申請，比如12306。但自己製作的證書是得不到CA認證的，所以訪問12306網站時，瀏覽器會有證書不合法的提示，如下圖，只有用戶選擇信任該網站時，才能繼續訪問。
三、數據的完整性
網絡傳輸過程中需要經過很多中間節點，雖然數據無法被解密，但可能被篡改，那如何校驗數據的完整性呢？通過校驗數字簽名，流程見下圖：
首先來了解下哈希算法，哈希算法能夠將任意長度的字符串轉化爲固定長度的字符串，該過程不可逆，可用來作數據完整性校驗。
服務器在發送報文之前做了3件的事：
- 用哈希算法對報文提取定長摘要
- 用私鑰對摘要進行加密，作爲數字簽名
- 將數字簽名附加到報文末尾發送給客戶端
客戶端接收到報文後：
- 用公鑰對服務器的數字簽名進行解密
- 用同樣的算法重新計算出報文的數字簽名
- 比較解密後的簽名與自己計算的簽名是否一致，如果不一致，說明數據被篡改過。
同樣，客戶端發送數據時，通過公鑰加密報文摘要，服務器用私鑰解密，用同樣的方法校驗數據的完整性。
HTTPS通信的大致過程
客戶端將自己支持的加密算法發送給服務器，請求服務器證書；
服務器選取一組加密算法，並將證書返回給客戶端；
客戶端校驗證書合法性，生成隨機對稱密鑰，用公鑰加密後發送給服務器；
服務器用私鑰解密出對稱密鑰，返回一個響應，HTTPS連接建立完成；
隨後雙方通過這個對稱密鑰進行安全的數據通信。
思考
通過HTTPS，客戶端一旦發現證書不合法或者數據被篡改，就是中止連接，文章開頭說的中間人攻擊就無效了。
下一篇介紹抓包工具是如何抓取HTTPS請求的?