當我們在談論 HTTPS 的時候，我們在談論什么？
我覺得，這些方面必不可少——

1. https 是什么？
2. https 與 http 的區別
3. https 設計原理
4. https 密鑰互換過程

https 是什么？

（此處已假設你熟悉并理解 http 協議，如不懂可以參考我另一篇文章）

https 是我們日常編程常用到的與安全有關的網絡協議， https 俗稱是基于 SSL/TLS 的 http 協議。

SSL/TLS 是什么呢？
可以理解為是一種安全協議，相當于網絡協議的安全套接層。

那 https 協議其實就相當于是在 http 協議外面套了一層安全協議，這就是 https 協議。

為什么要套這層SSL/TLS安全協議呢？因為 http 是不安全的。

了解過web安全應該知道 http 協議是明文通信的，那么就會帶來3個安全問題：

1. 竊聽風險：第三方可以獲知通信內容
2. 篡改風險：第三方可以修改通信內容
3. 冒充風險：第三方可以冒充他人身份參與通信

而 https 的誕生就恰好是為了解決這3個問題的。在 tcp 層與 http 層之間加入了 SSL/TLS ，來為通信提供網絡安全信道。

https 與 http 的區別

• http 是由“http://”起始與默認使用80端口，而https的URL則是由“https://”起始與默認使用443端口
• http 是明文傳輸信息的，https 是加密（對稱加密+非對稱加密）傳輸信息的。
• http不是安全的，而且攻擊者可以通過監聽和中間人攻擊等手段，獲取網站帳戶和敏感信息等。https 的設計可以防止前述攻擊，在正確配置時是安全的
• https 需要到 CA 申請證書，http 不需要證書

暫時我能想到的區別就這么多，歡迎補充：）

https 設計原理

我在網上看到過一篇文章，采用信鴿傳信的例子來形象生動的說明了 https 的設計原理。

主人公愛麗絲、鮑勃是一對情侶，馬洛里是第三者，現在處在愛麗絲和鮑勃需要用信鴿傳密信。

最初，愛麗絲和鮑勃是采用最簡陋的通信傳輸方式，就是信件內容不加密也不做任何處理。這時候他們發現，他們的信件內容經常被人竊聽、篡改甚至被冒充的人發信件。原來，他們的信鴿中途被馬洛里偷偷抓住了，因此他們的通信其實是不可靠的。

類比過來，這大概就是 http 協議實現的過程。

后來，聰明的鮑勃將信的內容進行加密，即他們事前約定好怎么解密（如將每個字母如 a 均向后移動3位，此時變成 d）。 于是馬洛里截獲的就是加密過的內容，馬洛里就不知道他們的通信內容了。

但是馬洛里也非常聰明，他慢慢發現了信件被加密了，不知道從哪里就弄到了解密的方法，于是他們的通信方式再一次變得不可靠。

于是愛麗絲他倆又發明了新的通信方法：愛麗絲先用信鴿寄一個空的帶鎖的匣子給鮑勃，而且這個匣子也沒有鎖上，這個鎖有且只有一把鑰匙，這時候是在愛麗絲手上。鮑勃拿到空匣子之后將加密過的內容放入匣子中，然后鎖上一并寄給愛麗絲。

這時候馬洛里再截獲信鴿也沒有用了，因為就算他知道信件里面內容的解密方法，但是他打不開這個盒子，因為只有愛麗絲有鑰匙能夠打開這個裝信件的匣子。這便是 https 通信中非對稱加密的精髓了。

但是怎么保障這個匣子就一定是最初愛麗絲寄給鮑勃的那個匣子呢？愛麗絲決定簽名標記一下盒子，這樣鮑勃收到盒子的時候就可以檢查簽名來確定是愛麗絲送出的盒子了。

村里比較有名望的泰德給人簽名，且他簽過的名他一定是可以認出來的，所有人可以信任他。這就是 https 原理設計中的向 CA 申請證書，泰德就相當于是 CA 機構。

這時候愛麗絲寄的匣子可以先找泰德簽名，然后鮑勃收到匣子也跟泰德確認是不是愛麗絲的匣子，最后匣子回到愛麗絲手中的時候她再跟泰德確認一遍該簽名。這樣就完全保證了愛麗絲、鮑勃的信鴿通信是完全可靠的。

這邊是 https 協議設計的大致過程。

其中，愛麗絲-鮑勃就是我們開發中的服務端和客戶端模型， 馬洛里可以想象成網絡黑客，匣子是公鑰，匣子的鑰匙是私鑰，然后泰德就是證書認證機構 CA。

信件加密采用的是對稱加密，寄匣子然后自己留唯一鑰匙的方式采用的是非對稱加密。這樣他們的通信方式就兼具非對稱加密的可靠性和對稱加密的高效性了。

“非對稱加密算法”：從數學上確保了——即使你知道某個公鑰，也很難（不是不可能，是很難）根據此公鑰推導出對應的私鑰。
“對稱加密”：只要知道了加密算法，人人都可以用這個加密算法解開經過對稱加密的內容。

https 密鑰互換過程

了解了https協議的設計原理，https 的通信過程就比較好理解了。唯一需要重點注意的，就是 https 密鑰交換 的過程（這個很多大廠前端面試會考到哦）。

https 密鑰交換過程大致如下圖所示：

https.png

1. 客戶端發起HTTPS請求
   這個沒什么好說的，就是用戶在瀏覽器里輸入一個https網址，然后連接到server的443端口。

2. 服務端的配置
   采用HTTPS協議的服務器一般會向 CA 申請一套數字證書。這套證書其實就是一對公鑰和私鑰，即公鑰加密過的內容，只有私鑰才能解密。如果覺得這不太好理解，公鑰和私鑰可以想象成上面例子中的那個匣子和開匣子的鑰匙。

3. 傳送證書
   這個證書其實就是公鑰，只是包含了很多信息，如證書的頒發機構，過期時間等等。

4. 客戶端解析證書
   這部分工作是由客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發機構，過期時間等等，如果發現異常，則會彈出一個警告框，提示證書存在問題。如果證書沒有問題，那么就生成一個隨即值（如上圖的 k）。然后用證書的公鑰 k2 對該隨機值k進行加密 得到 k‘。就好像上面說的，把隨機值用鎖頭鎖起來，這樣除非有鑰匙，不然看不到被鎖住的內容。

5. 傳送加密信息
   這部分傳送的是用證書加密后的隨機值k’，目的就是讓服務端也得到這個隨機值，以后客戶端和服務端的通信就可以通過這個隨機值來進行加密解密了。

6. 服務端解密信息
   服務端用私鑰k1解密k‘后，得到了客戶端傳過來的隨機值k(私鑰)，然后把內容通過該值進行對稱加密。所謂對稱加密就是，將信息和私鑰通過某種算法混合在一起，這樣除非知道私鑰，不然無法獲取內容，而正好客戶端和服務端都知道這個私鑰，所以只要加密算法夠彪悍，私鑰夠復雜，數據就夠安全。

7. 傳輸加密后的信息
   這部分信息是服務段用私鑰加密后的信息，可以在客戶端被還原。

8. 客戶端解密信息
   客戶端用之前生成的私鑰解密服務端傳過來的信息，于是獲取了解密后的內容。整個過程第三方即使監聽到了數據，也束手無策。

需要注意的是，客戶端和服務器端雙方最終采用 "對話密鑰"（上圖中的 k，通過雙方協商生成） 進行加密通信的，而非最開始從從 CA 那里申請得到的公鑰或私鑰。