1. HTTP存在的問題

傳統的不使用SSL/TLS的HTTP協議，是不加密的通信，無論是客戶端發送給服務端的請求體，還是服務端回應給客戶端的回應體，都是明文傳輸的，這會帶來幾個問題：

1. 竊聽
第三方劫持請求后可以獲取通信內容，對于一些敏感資料，這是不被允許的，

2. 篡改
第三方劫持請求后可以篡改通信內容，例如銀行系統中，張三本來要給李四轉賬，第三方劫持請求后篡改了請求資料，將收款方改為自己，導致用戶資金流失，

3. 冒充
第三方可以冒充客戶端發送資料，由于是明文傳輸，沒有「加簽/驗簽」操作，服務端無法保證請求來源的合法性，

正是因為這些問題，HTTP通信存在巨大的安全隱患，于是HTTPS出現了，
本文將一步步深入，看看HTTPS是如何解決這些問題的，

2. SSL/TLS

在介紹HTTPS之前，必須先了解SSL/TLS協議，因為HTTPS是構建在此基礎之上的，了解了SSL/TLS基本也就清楚HTTPS的作業原理了，

SSL（Secure Sockets Layer）譯為「安全套接字協議」，TLS（Transport Layer Security）譯為「傳輸層安全性協議」，

簡單回顧一下它們的發展歷史吧：

• 1994年，網景公司設計了SSL協議（Secure Sockets Layer）的1.0版，但是未發布，
• 1995年，網景公司發布SSL 2.0版，但很快發現有嚴重漏洞，
• 1996年，SSL 3.0版問世，得到大規模應用，
• 1999年，互聯網標準化組織ISOC接替網景公司，發布了SSL的升級版TLS 1.0版，
• 2006年和2008年，TLS進行了兩次升級，分別為TLS 1.1版和TLS 1.2版，

SSL/TLS協議處于「傳輸層」和「應用層」之間，主要作用是對網路連接進行加解密，如下圖：

2.1 防竊聽：加密

先來看看第一個問題：竊聽，既然明文傳輸可以被第三方竊聽資料，那么改為加密傳輸不就行了嗎？
方向是對的，但是如何加密才能保證資料的安全呢？

2.1.1 對稱加密

采用單鑰密碼系統的加密方法，同一個密鑰可以同時用作資訊的加密和解密，這種加密方法稱為對稱加密，也稱為單密鑰加密，

例如DES就是一種對稱加密演算法，甲乙雙方約定一個密鑰「Key」，雙方發送資料前都用該密鑰對資料進行加密傳輸，收到資料后再解密成明文即可，這種方式，只要保證密鑰不被泄漏，理論上也是安全的，

但是這會帶來一個新的問題：密鑰如何保存？

對于PC端來說，瀏覽器頁面是明文的，肯定不能存盤密鑰，對于iOS/Android來說，即使把密鑰藏在安裝包的某個位置，也很容易被第三方拆包破解，

既然客戶端保存不靠譜，那么密鑰只在服務端保存，客戶端去向服務端拿密鑰是否可行？

依然不可行，服務端要怎么把密鑰給你呢？明文肯定不行，如果要加密，又要用到密鑰B，密鑰B的傳輸又要用到密鑰C，如此回圈，無解，

2.1.2 非對稱加密

非對稱加密演算法需要兩個密鑰：公開密鑰（publickey:簡稱公鑰）和私有密鑰（privatekey:簡稱私鑰），公鑰與私鑰是一對，如果用公鑰對資料進行加密，只有用對應的私鑰才能解密，因為加密和解密使用的是兩個不同的密鑰，所以這種演算法叫作非對稱加密演算法，

甲乙雙方各有一套自己的密鑰對，互相公開彼此的公鑰，當甲方要發送資料給乙方時，用乙方公鑰加密，這樣密文就只有乙方自己能解開了，就算請求被劫持，第三方拿到了資料，由于沒有乙方的私鑰，也無法解密，這樣就保證了資料被竊聽，

單向非對稱加密
絕大多數互聯網網站對外是完全公開的，所有人都可以訪問，服務端沒必要驗證所有客戶端的合法性，只有客戶端需要驗證服務端的合法性，例如用戶在訪問電商網站時，必須確保不是釣魚網站，以防資金損失，

這種情況下，只需要單向加密即可，服務端發送給客戶端的一般不會有敏感資訊，明文傳輸即可，但是客戶端發送給服務端的就很有可能是敏感資訊，例如用戶修改密碼，這時就必須加密傳輸了，

雙向非對稱加密
有時，服務端也需要驗證客戶端的合法性，例如銀行系統，由于涉及到金錢，因此系統必須設計的足夠安全，除了客戶端發送給服務端的資料是加密的，服務端發送給客戶端的資料也必須加密，

怎么做的呢？一般銀行會給用戶一個U盤，里面存盤的就是一套密鑰對，客戶端告訴服務端自己的公鑰，服務端根據公鑰加密后再傳輸給客戶端，

2.2 防篡改：加簽

通過非對稱加密的密文傳輸，可以防止資料被竊聽，但是如果存在這種場景呢？

張三登陸銀行系統，要給李四轉一筆錢，資料通過服務端的公鑰PubB加密傳輸，但是第三方劫持了這個請求，篡改了報文資料，寫入的是「給王五轉錢」，因為服務端的公鑰是公開的，誰都能拿到，因此第三方也可以正常加密傳輸，服務端正常解密后進行了錯誤的操作，導致用戶資金流失，

對于涉及到資金的操作，服務端必須要驗證資料的合法性，確保資料沒有被篡改，這就需要客戶端對資料進行加簽了，

非對稱加密除了可以「公鑰加密，私鑰解密」外，還可以「私鑰加簽，公鑰驗簽」，

銀行給用戶一個U盤，里面有一套密鑰對，客戶端在發送轉賬請求前，先對請求體加簽，得到簽名「sign」，然后再用服務端公鑰加密，得到密文「data」，客戶端將簽名和密文一起發送給服務端，服務端解密后，還需要用客戶端的公鑰對「sign」進行驗簽，只有驗簽通過才能進行后續操作，否則就是非法請求了，

這樣，即使請求被第三方劫持了，第三方可以篡改資料，但是簽名它改不了，服務端解密后會發現資料和「sign」對不上，說明資料是被篡改過的，

2.3 防冒充：證書

通過加密防止資料被竊聽，通過加簽防止資料被篡改，現在看來好像已經很安全了，但是別忘了，有個前提是：公鑰的傳輸是安全的，不幸的是，公鑰的安全傳輸很難保證，

中間人攻擊
假設存在這樣一種場景，客戶端和服務端想互換公鑰，但是請求都被一個中間人劫持了，結果就是：服務端和客戶端以為是和雙方互換公鑰了，結果是客戶端和服務端都和中間人互換公鑰了，

一旦出現這種問題就非常嚴重，前面講到的加密解密、加簽驗簽都失效了，客戶端以為中間人就是服務端，服務端以為中間人就是客戶端，雙方以為是在和對方通信，其實都是在和中間人通信，中間人可以隨意的竊聽和篡改資料，

這個問題之所以會出現，就是因為公鑰的傳輸是不安全的，客戶端和服務端之間互換公鑰時，如何確保公鑰就是對方發出的，沒有被篡改過呢？？？

2.3.1 數字證書與認證中心

在之前的基礎上，引入一個中間角色：證書認證中心CA，當服務端要把公鑰發送給客戶端時，不是直接發送公鑰，而是先把公鑰發送給CA，CA根據公鑰生成一份「證書」給到服務端，服務端將證書給客戶端，客戶端拿到證書后去CA驗證證書的合法性，確保證書是服務端下發的，

CA就類似于「公證處」，也是一臺服務器，它自己本身也有一套密鑰對，它的作業就是根據服務端的公鑰生成證書，然后幫助客戶端來驗證證書的合法性，

2.3.2 CA被冒充怎么辦？

引入CA可以保證公鑰的傳輸安全，但是有一個前提，客戶端和服務端是信任CA的，也就是說CA必須是安全可信任的，如果CA被冒充，就又會出現上面的問題，

基于這個問題，就引入了「根證書」和「CA信任鏈」的概念，

要讓客戶端和服務端信任CA，其實CA也面臨著同樣的問題，那就是：如何保證CA的公鑰是安全不被篡改的？答案也是一樣的，就是給CA也頒發證書，那這個證書由誰來頒發呢？自然是CA的上一級CA了，CA的上一級CA如何保證安全？那就CA的上一級CA的上一級CA給它頒發證書了，最終就會形成一個證書信用鏈，如下：

客戶端要想驗證服務器的C3證書是否合法，會跑去CA2驗證，要驗證CA2就去CA1驗證，以此類推，對于根證書，是沒法驗證的，只能無條件相信，因為Root CA都是國際上公認的機構，一般用戶的作業系統或瀏覽器在發布時，就會在里面嵌入這些機構的Root證書，

如下是百度官網的證書，點擊瀏覽器地址欄旁邊的鎖標識就能看到了，

2.4 SSL/TLS 四次握手

了解了底層的實作，加密、加簽、證書等概念后，再來看SSL/TLS協議就很容易理解了，SSL/TLS需要四次握手的程序：

1. 客戶端向服務端所有證書，
2. 服務端發送證書，
3. 客戶端驗證證書，提取公鑰，發送對稱加密的密鑰，
4. 服務端收到密鑰，回應OK，

3. 再看HTTPS

了解SSL/TLS，再回過頭來看HTTPS就很簡單了，HTTPS=HTTP+SSL/TLS，

使用HTTPS進行通信時，先是建立傳輸層TCP的連接，完成三次握手，然后再是SSL/TLS協議的四次握手，雙方協商出對稱加密的密鑰，之后的通信資料會利用該密鑰進行加密傳輸，

HTTP1.1開始支持長連接了，只要連接不關閉，七次握手只需要執行一次，性能損耗不會太大，而且資料傳輸采用的是對稱加密，相比于非對稱加密，性能損耗也小得多，因此HTTPS相比于HTTP，性能會有一定影響，但不會太大，相比之下，資料傳輸安全顯得更加重要！