在說HTTPS之前，我們先說說HTTP通信過程中的一些問題風險

無加密處理的HTTP

HTTP爲我們的網絡通信帶來了很多益處，但HTTP同樣也有它的缺點，我們知道，HTTP是一個未加密的協議，所以在傳輸過程中，它有可能遇到以下風險

1. 竊聽風險

通信使用明文（不加密），內容可能會被竊聽
事實上，即使是已經加密了的通信，也會被窺視到通信內容，只是通過加密處理，別人可能無法得知傳輸內容的真實信息
竊聽相同段上的通信，只需要手機在互聯網上流動的數據包（幀）就行了。對於收集來的數據包的解析工作，課交給那些抓包或嗅探器工具。比如Wireshark，相關的抓包原理可見wireshark學習筆記----抓包網絡原理

加密處理防止竊聽

目前如何解決竊聽風險的幾種對策中，最爲普及的就是加密技術了。

通信的加密

一種方式是將通信加密，雖然HTTP沒有加密處理，但我們可以通過和SSL（Secure Socket Layer 安全接套層）或TLS（Transport Layer Security 安全傳輸協議）的組合使用，加密HTTP的通信內容

內容的加密

除了對通信的過程進行加密外，我們也可以對內容來進行一個加密。其實這就像一種翻譯，只要能竊聽到你通信內容的人都看不懂你寫的這種語言，而接受內容的人懂，那就不怕內容會被竊聽了。所以這種內容的加密，要求客戶端和服務器端雙方都同時具備加密和解密機制。

但由於只是對內容進行加密，所以不同於通信加密，在傳輸過程中還是有被篡改的風險的。

2. 冒充風險

不驗證通信方的身份，因此有可能遭遇僞裝
在HTTP通信時，由於不存在確認通信方的步驟，所以任何人都可以發起請求。而服務端只要接受到請求，不管是誰發出的，都會返回一個響應。

這樣的做法，就導致了以下的問題

客戶端發起的請求，無法確認是否真的發送到想要發送到的服務器那裏，有可能是冒充的服務器返回給給客戶端響應
無法確定返回的響應是否真的返回給了正確的客戶端，可能會被返回到冒充的客戶端
無法確定正在通信的對方是否具備訪問權限，因爲部分Web服務器上保存着重要的信息，只想發給特定的用戶通信的權限。
無法判斷請求是誰發出的
即使是無意義的請求也會照單全收，無法阻止海量請求下的DoS攻擊（Denial of Service，拒絕服務攻擊）

通過SSL提供證書

雖然使用HTTP協議無法確定通信方，但如果使用SSL則可以。SSL不僅有我們上面提到的通信加密處理，還提供了證書，可用於確定通信方。
證書由值得信任的第三方機構頒發，用以證明服務器和客戶端是實際存在的。從技術角度上來說，僞造證書是很困難的，所以基本上只要我們能夠確認通信方持有的證書，即可判斷通信方的真實意圖。
在http狀態碼中，401就是用來表示需要提供證書但沒有證書的錯誤

3. 篡改風險

無法證明報文的完整性，所以有可能已經已遭篡改

由於HTTP無法證明報文的完整性，所以如果在客戶端發送請求到服務端和服務端接受到請求報文這段時間內，或者是服務端返回響應報文到客戶端獲得響應報文的這段時間內，報文內容被修改了，HTTP是無法得知的。
這種從中間的這段時間攔截並篡改內容的攻擊叫做中間人攻擊（Man-in-the-Middle attack，MITM）

跟上面兩種風險的解決方式一樣，這裏我們仍要使用到SSL。在使用SSL協議時，會在應用層附加一種叫做MAC的報文摘要，MAC能夠查知報文是否遭到篡改，從而保護報文的完整性。

HTTPS對於風險的處理

在《圖解HTTP》中有這麼一條等式

HTTP+加密+認證+完整保護 = HTTPS

可以從這條等式看出，HTTPS實際上就是用來解決上面提到過的那些風險的，那麼具體是怎麼做到的呢，我們先簡單認識以下SSL/TLS協議

SSL/TLS協議

我們知道，HTTPS是基於SSL/TLS協議之上的，不使用SSL/TLS協議的HTTP通信，即不加密的通信，所有的信息在傳輸的時候都會以明文的形式進行一個傳輸，那麼就會帶來以下風險
SSL/TLS協議爲了解決以上風險，希望達到

1. 所有信息都是加密傳輸，第三方無法竊聽
1. 具有校驗機制，一旦發生更改，傳輸雙方都能發現
1. 配備身份證書，防止身份被冒充

相互交換密鑰的公開密鑰加密技術

SSL採用一種公開密鑰加密的加密處理方式
近代的加密方法中加密算法是公開的，而密鑰是保密的，也就是說公開了上鎖的方法，但是開鎖的鑰匙藏起來了，通過這種方式來保持加密方法的安全性

共享密鑰加密（對稱加密）的困境

在密鑰加密技術中，我們將加密和解密共用一個密鑰的方式稱爲共享密鑰加密，也被稱爲對稱密鑰加密

使用對稱加密必須將密鑰也發送給對方，但這就涉及到一個問題，我們如何將密鑰發送給對方，如果直接發送，那密鑰就可能被別人監聽獲取，那別人也就可以對信息進行加密解密，加密就變得沒有意義了

而如果我們能做到安全地發送密鑰了，那說明數據也可以安全發送了，那又何必發送密鑰來加密呢

使用兩把密鑰的公開密鑰加密

爲了解決上面的問題，我們可以採用非對稱密鑰加密，使用兩把密鑰，一把私有密鑰，一把公有密鑰。

所謂私有，自然就是不能被他人知道的，而公有密鑰，是每個人都能知道的。使用公開密鑰加密方式，發送密文的以方使用對方的公開密鑰進行加密，對方收到被加密的信息後，再使用自己的私有密鑰進行解密。

簡單來說，就是一個鎖，我們可以用公有的鑰匙上鎖，但是打開卻只能用特有的一把私有的鑰匙打開，只要自己不把私有的鑰匙交出去，別人就無法去打開這個鎖。

回到網絡中，使用非對稱加密，一開始由接收信息的一方，將公開密鑰交給發送信息的一方，發送信息的一方使用該公開密鑰對要發送的信息進行一個加密，發送給接收方，接收方再使用自己的私有密鑰對信息進行解密，獲取真正的內容。

這個方法的安全實現，需要一個技術上的不支持，那就是無法或者很難通過公開密鑰和加密後的信息推導出原信息，否則公開密鑰是所有人都能拿到的，而加密後的信息在傳輸過程中是可能被監聽的，可以推導的話這個加密方法也顯得不安全了。

好在要想根據密文和公開密鑰，恢復到信息原文是異常困難的。在《圖解HTTP》中就說到了

因爲解密過程就是在對離散對數進行求職，這並非輕而易舉就能辦到。退一步講，如果能對一個非常大的整數做到快速地因式分解，那麼密碼破解還是存在希望的。但就目前的技術來看是不太現實的。

HTTPS採用混合加密機制

雖然我們使用非對稱的加密比起對稱加密來說更爲安全，但是非對稱加密比起對稱加密來說，消耗的時間更多，爲了整合兩者的優點，我們結合這兩種方式來完成信息傳輸，這裏會用到三把密鑰，非對稱加密的兩把密鑰，一把私有，一把公有，以及對稱加密的一把公有密鑰

我們知道，對稱加密的問題就在於，我們無法保證公開密鑰不會被他人知道，而通過使用非對稱加密，我們可以講公開密鑰安全地交給發送方

所以，混合機密機制就是，在一開始通過使用非對稱加密，將對稱加密要用到的公開密鑰交給發送方，然後後面的信息傳遞，都使用對稱加密來對信息進行加密，這樣後面的信息傳遞在加密這部分消耗的時間就會比較小，又通過非對稱加密，保證了公開密鑰的安全傳輸。

證明公開密鑰正確性的證書

雖然我們上面採用的混合加密機制看起來好像已經足夠安全了，但存在一個問題，我們如何確定一開始給我們發送對稱加密時要用到的公開密鑰的那個服務器，就是我們最終要連接的那個服務器呢。有可能在發送公開密鑰的時候，發送密鑰的這個服務器就是別人僞造的。

爲了解決上面這個問題，可以使用由數字證書認證機構和其相關機關頒發的公開密鑰證書。

數字證書認證機構出於客戶端與服務器雙方都可信賴的第三方機構的立場上，在判明提出申請者的身份之後，會對已申請的公開密鑰做數字簽名，然後分配這個已簽名的公開密鑰，並將該公開密鑰放入公鑰證書後綁定在一起。

所以，除了上面的混合加密機制中說到的步驟外，服務器還應將這份由數字證書認證機構辦法的公鑰證書發送給哭護短，以進行公開密鑰加密方式通信。而接收到證書的客戶端可使用數字證書認證機構的公開密鑰，對那張證書上的數字簽名進行驗證，一旦驗證通過，客戶端便可明確認證服務器的公開密鑰時真實有效的數字證書認證機構，且服務器的公開密鑰時值得信賴的。

整體步驟：

服務器把自己的公開密鑰登錄至數字證書認證機構
數字證書認證機構用自己的私有密鑰向服務器的公開密碼部署數字簽名並辦法公鑰證書
服務器將公開密鑰和數字證書認證機構的數字簽名發送給客戶端
客戶端拿到公鑰證書後，使用數字證書認證機構的公開密鑰想數字證書認證機構驗證公鑰證書上的數字簽名後，以確認服務器的公開密鑰真實性
客戶端使用服務器的公開密鑰對報文進行加密後發送
服務器用私有密鑰對加密信息進行解密

HTTPS的安全通信機制

客戶端通過發送Client Hello報文開始SSL通信。報文中包含客戶端支持的SSL的指定版本、加密組件列表
服務器可進行SSL通信時，會以Server Hello報文做爲應答。和客戶端一樣，在報文中包含SSL版本以及加密組件。
之後服務器發送Certificate報文。報文中包含公開密鑰證書。
最後服務器發送Server Hello Done報文通知客戶端，最初階段的SSL握手協商部分結束。
SSL第一次握手結束知乎，客戶端以Client Key Exchange報文作爲迴應。報文中包含通信加密中使用的一種被稱爲Pre-master secret的隨機密碼串。該報文已用步驟3中的公開密鑰進行加密。
接着客戶端繼續發送Change Cipher Spec報文。該報文會提示服務器，在此報文之後的通信會採用Pre-master secret密鑰加密。
客戶端發送Finished報文。該報文包含連接至今全部報文的整體校驗值。這次握手協商是否能成功，要以服務器是否能夠正確解密該報文做爲判定標準。
服務器同樣發送Change Cipher Spec報文。
服務器同樣發送Finished報文。
服務器和客戶端的Finished報文交換完畢之後，SSL連接就算建立完成。從此處開始，進行應用層協議的通信，即發送HTTP請求。
最後由客戶端斷開連接。

HTTPS的缺點

HTTPS帶來安全性的同時，不可避免地帶來了一些缺點，最顯著的，就是由於增加了很多額外的操作，導致處理速度變慢。

當HTTPS使用SSL時，有兩個方面會導致處理速度變慢

需要做服務器、客戶端雙方加密及解密處理，因此會消耗CPU和內存等硬件資源。
和HTTP通信相比，SSL通信部分消耗網絡資源。而SSL通信部分，又因爲要對通信進行處理，所以時間上又延長了。

在《圖解HTTP》中提到

針對速度變慢這一問題，並沒有根本性的解決方案，我們會使用SSL加速器這種（專用服務器）硬件來改善問題。

除了速度變慢外，我們還需要去向認證機構購買使用的證書，而實際上，我們的一些個人網站完全沒必要去做這樣的安全性考慮，爲這種意義不大的安全性考慮而花費經濟，顯然是不合算的。

參考文章：
https://developers.weixin.qq.com/community/develop/article/doc/000046a5fdc7802a15f7508b556413
http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html

參考書籍：
《圖解HTTP》

從HTTP的安全問題到HTTPS