HTTPS（Hypertext Transfer Protocol Secure，超文本傳輸安全協議），是以安全為目標的 HTTP 通道，簡單講是 HTTP 的安全版。本文，就來深入介紹下其原理。
為什麼需要 HTTPS
使用 HTTPS 的原因其實很簡單，就是因為 HTTP 的不安全。
當我們往服務器發送比較隱私的數據（比如說你的銀行卡，身份證）時，如果使用 HTTP 進行通信。那麼安全性將得不到保障。
首先數據在傳輸的過程中，數據可能被中間人抓包拿到，那麼數據就會被中間人竊取。
其次數據被中間人拿到後，中間人可能對數據進行修改或者替換，然後發往服務器。
最後服務器收到數據後，也無法確定數據有沒有被修改或替換，當然，如果服務器也無法判斷數據就真的是來源於客戶端。
總結下來，HTTP 存在三個弊端：
HTTPS 就是為了解決上述問題應運而生的。
HTTPS 基本概念
為了解決 HTTP 中存在的問題，HTTPS 採用了一些加解密，數字證書，數字簽名的技術來實現。下面先介紹一下這些技術的基本概念。
對稱加密與非對稱加密
為了保證消息的保密性，就需要用到加密和解密。加解密算法目前主流的分為對稱加密和非對稱加密。
①對稱加密（共享密匙加密）：客戶端和服務器公用一個密匙用來對消息加解密，這種方式稱為對稱加密。
客戶端和服務器約定好一個加密的密匙。客戶端在發消息前用該密匙對消息加密，發送給服務器後，服務器再用該密匙進行解密拿到消息。
對稱加密的優點：對稱加密解決了 HTTP 中消息保密性的問題。
對稱加密的缺點：對稱加密雖然保證了消息保密性，但是因為客戶端和服務器共享一個密匙，這樣就使得密匙特別容易洩露。因為密匙洩露風險較高，所以很難保證消息來源的可靠性、消息的完整性和準確性。
②非對稱加密（公有密匙加密）：既然對稱加密中，密匙那麼容易洩露，那麼我們可以採用一種非對稱加密的方式來解決。
採用非對稱加密時，客戶端和服務端均擁有一個公有密匙和一個私有密匙。公有密匙可以對外暴露，而私有密匙只有自己可見。
使用公有密匙加密的消息，只有對應的私有密匙才能解開。反過來，使用私有密匙加密的消息，只有公有密匙才能解開。
這樣客戶端在發送消息前，先用服務器的公匙對消息進行加密，服務器收到後再用自己的私匙進行解密。
非對稱加密的優點：
非對稱加密的缺點：
數字證書與數字簽名
為了解決非對稱加密中公匙來源的不安全性。我們可以使用數字證書和數字簽名來解決。
①數字證書的申請
在現實中，有一些專門的權威機構用來頒發數字證書，我們稱這些機構為認證中心（CA，Certificate Authority）。
我們（服務器）可以向這些 CA 來申請數字證書。申請的過程大致是：自己本地先生成一對密匙，然後拿著自己的公匙以及其他信息（比如說企業名稱啊什麼的）去 CA 申請數字證書。
CA 在拿到這些信息後，會選擇一種單向 Hash 算法（比如說常見的 MD5）對這些信息進行加密，加密之後的東西我們稱之為摘要。
單向 Hash 算法有一種特點就是單向不可逆的，只要原始內容有一點變化，加密後的數據都將會是千差萬別（當然也有很小的可能性會重複，有興趣的小夥伴瞭解一下鴿巢原理），這樣就防止了信息被篡改。
生成摘要後還不算完，CA 還會用自己的私匙對摘要進行加密，摘要加密後的數據我們稱之為數字簽名。
最後，CA 將會把我們的申請信息（包含服務器的公匙）和數字簽名整合在一起，由此而生成數字證書。然後 CA 將數字證書傳遞給我們。
②數字證書怎麼起作用
服務器在獲取到數字證書後，服務器會將數字證書發送給客戶端，客戶端就需要用 CA 的公匙解密數字證書並驗證數字證書的合法性。
那我們如何能拿到 CA 的公匙呢？我們的電腦和瀏覽器中已經內置了一部分權威機構的根證書，這些根證書中包含了 CA 的公匙。
之所以是根證書，是因為現實生活中，認證中心是分層級的，也就是說有頂級認證中心，也有下面的各個子級的認證中心，是一個樹狀結構，計算機中內置的是最頂級機構的根證書，不過不用擔心，根證書的公匙在子級也是適用的。
客戶端用 CA 的公匙解密數字證書，如果解密成功則說明證書來源於合法的認證機構。解密成功後，客戶端就拿到了摘要。
此時，客戶端會按照和 CA 一樣的 Hash 算法將申請信息生成一份摘要，並和解密出來的那份做對比，如果相同則說明內容完整，沒有被篡改。
最後，客戶端安全的從證書中拿到服務器的公匙就可以和服務器進行安全的非對稱加密通信了。服務器想獲得客戶端的公匙也可以通過相同方式。
下圖用圖解的方式說明一般的證書申請及其使用過程：
HTTPS 原理
通過上面的學習，我們瞭解了對稱加密與非對稱加密的特點和優缺點，以及數字證書的作用。
HTTPS 沒有采用單一的技術去實現，而是根據他們的特點，充分的將這些技術整合進去，以達到性能與安全最大化。
這套整合的技術我們稱之為 SSL（Secure Scoket Layer，安全套接層）。所以 HTTPS 並非是一項新的協議，它只是在 HTTP 上披了一層加密的外殼。
HTTPS 的建立，先看一下流程圖：
這裡把 HTTPS 建立到斷開分為 6 個階段，12 個過程。下面將對 12 個過程一 一做解釋：
另外，在以上流程圖中，應用層發送數據時會附加一種叫做 MAC（Message Authentication Code）的報文摘要。MAC 能夠查知報文是否遭到篡改，從而保證報文的完整性。
下面再用圖解來形象的說明一下，此圖比上面數字證書的圖更加的詳細一些（圖片來源於《圖解 HTTP》）：
經過上面的介紹，我們可以看出 HTTPS 先是利用數字證書保證服務器端的公匙可以安全無誤的到達客戶端。
然後再用非對稱加密安全的傳遞共享密匙，最後用共享密匙安全的交換數據。
HTTPS 的使用
HTTPS 那麼的安全，是不是我們在什麼場景下都要去使用 HTTPS 進行通信呢？答案是否定的。
①HTTPS 雖然提供了消息安全傳輸的通道，但是每次消息的加解密十分耗時，消耗系統資源。
所以，除非在一些對安全性比較高的場景下，比如銀行系統，購物系統中我們必須要使用HTTPS 進行通信，其他一些對安全性要求不高的場景，我們其實沒必要使用 HTTPS。
②使用 HTTPS 需要使用到數字證書，但是一般權威機構頒發的數字證書都是收費的，而且價格也是不菲的。
所以對於一些個人網站來講，如果對安全性要求不高，也沒必要使用 HTTPS。
作者：安靜的boy編輯：陶家龍、孫淑娟出處：轉自公眾號：Hollis（ID：hollischuang）
