https/tls原理
HTTPS訪問的三個階段
第一階段 認證站點
客戶端向站點發起HTTPS請求，站點返回數字證書。客戶端通過數字證書驗證所訪問的站點是真實的目標站點。
第二階段 協商密鑰
客戶端與站點服務器協商此次會話的對稱加密密鑰，用於下一階段的加密傳輸。
第三階段 加密傳輸
客戶端與站點直接使用已協商的對稱加密密鑰傳輸數據。
以下用一張圖描繪CA、站點服務器、客戶端之間的交互關係
中間人攻擊
中間人攻擊的幾種形式
- 直接抓取報文獲得明文信息
- 非法中間加密代理，竊取明文信息
- 留存密文，如果對稱密鑰泄露，解密歷史報文
中間人攻擊的防範
防範直接獲取明文
加密傳輸報文
防範非法中間加密代理
黑客對客戶端僞裝成服務器，對服務器僞裝成客戶端，通過非法代理竊取會話數據。上面圖示的第一、第二階段可以防止這種非法代理行爲。雖然黑客可以獲取站點的證書，僞裝成站點服務器接收請求，但黑客沒有站點服務器私鑰，無法與實現客戶端實現密鑰交換，不能竊取明文的會話數據。
防範解密歷史報文（前向安全性）
防範解密歷史報文，這種安全防護叫前向安全。早期的HTTPS實現中，客戶端將會話密鑰通過站點公鑰加密後，發送給服務器，服務器用私鑰解密。此時如果服務器私鑰保管不善泄露，黑客如果留存了歷史報文，可以解密獲取會話密鑰，從而還原歷史報文數據。目前通過DH算法保證前向安全。在第二階段，客戶端與服務器只交換少量信息，雙方便可獨立計算出臨時會話密鑰用於加密。即使黑客事後獲取私鑰，也不能計算出會話密鑰，從而實現前向安全。
FAQ
爲什麼不直接使用非對稱密鑰加密傳輸報文？
首先非對稱密鑰加解密效率低，不如對稱密鑰，一般使用AES等加密算法。其次前面也提到，只使用非對稱密鑰加解密不能保證前向安全性。
瀏覽器怎麼知道所訪問的站點不是僞造的？
瀏覽器主要依靠數字證書來確認所訪問的站點不是僞造的。當瀏覽器通過https訪問站點，站點須返回數字證書。數字證書是CA機構“簽發”的電子文件，其中包含使用者信息、站點公鑰、頒發者（CA）信息和CA指紋等。假設數字證書是完全可信的，且其中的內容也是不可篡改的。瀏覽器首先驗證數字證書中的使用者（站點）信息與所訪問的站點域名是否一致，然後用數字證書中的站點公鑰挑戰站點服務器，只用擁有私鑰的真實站點才能通過挑戰。因此可以確保所訪問的站點是真實的。
注意：如果驗證有問題，瀏覽器會提示風險訪問。
爲什麼數字證書是可信的？
CA機構是可信的，CA本身也包含一個非對稱密鑰對，私鑰用於“簽發”的數字證書，公鑰發佈出去用於驗證數字證書。CA使用非對稱密鑰配合HASH算法保證數字證書可信且不可篡改。CA將使用者信息、站點公鑰、有效期等關鍵信息打包做HASH運算，再將HASH運算結果用CA私鑰簽名生成指紋。然後將以上全部信息打包成數字證書。黑客沒有私鑰不可以僞造證書籤名，且證書的內容如果被修改，HASH結果就會改變。因此黑客不可僞造或者篡改證書，有效的數字證書是可信的。
瀏覽器怎麼知道CA是可信的？
瀏覽器主要依據客戶端操作系統保存的根證書列表判斷CA的權威性。如上圖，在Windows操作系統中，這個列表放在“受信任的根證書頒發機構存儲區”中，這個列表實際上是CA機構的根證書集合，根證書包含CA機構的信息和公鑰。只要是這個列表中的CA簽發的證書，瀏覽器就認爲可信。微軟會動態維護根證書列表，用戶需要管理員權限才能向這個列表中加入CA證書。
注：Windows客戶端運行在內網中時，若無法聯網更新根證書列表，此時可能會出向訪問https應用緩慢。解決方法如下：
爲什麼有些軟件如Fiddler可以還原https報文？
Fiddler是通過中間代理的方式抓取報文，還原https報文的前提是在客戶端的根證書列表下加入Fiddler生成的CA根證書。這樣Fiddler就成爲CA，可以僞造數字證書，僞裝成服務器。但是隻能用於測試，不能實現真正意義上的竊取數據。