為什麼需要https

HTTP是明文傳輸的，也就意味著，介於傳送端、接收端中間的任意節點都可以知道你們傳輸的內容是什麼。這些節點可能是路由器、代理等。

舉個最常見的例子，使用者登陸。使用者輸入賬號，密碼，採用HTTP的話，只要在代理伺服器上做點手腳就可以拿到你的密碼了。

使用者登陸 --> 代理伺服器（做手腳）--> 實際授權伺服器

在傳送端對密碼進行加密？沒用的，雖然別人不知道你原始密碼是多少，但能夠拿到加密後的賬號密碼，照樣能登陸。

HTTPS是如何保障安全的

HTTPS其實就是secure http的意思啦，也就是HTTP的安全升級版。稍微瞭解網路基礎的同學都知道，HTTP是應用層協議，位於HTTP協議之下是傳輸協議TCP。TCP負責傳輸，HTTP則定義了資料如何進行包裝。

HTTP --> TCP （明文傳輸）

HTTPS相對於HTTP有哪些不同呢？其實就是在HTTP跟TCP中間加多了一層加密層TLS/SSL。

神馬是TLS/SSL？

通俗的講，TLS、SSL其實是類似的東西，SSL是個加密套件，負責對HTTP的資料進行加密。TLS是SSL的升級版。現在提到HTTPS，加密套件基本指的是TLS。

傳輸加密的流程

原先是應用層將資料直接給到TCP進行傳輸，現在改成應用層將資料給到TLS/SSL，將資料加密後，再給到TCP進行傳輸。

大致如圖所示。

就是這麼回事。將資料加密後再傳輸，而不是任由資料在複雜而又充滿危險的網路上明文裸奔，在很大程度上確保了資料的安全。這樣的話，即使資料被中間節點截獲，壞人也看不懂。

HTTPS是如何加密資料的

對安全或密碼學基礎有了解的同學，應該知道常見的加密手段。一般來說，加密分為對稱加密、非對稱加密（也叫公開金鑰加密）。

對稱加密

對稱加密的意思就是，加密資料用的金鑰，跟解密資料用的金鑰是一樣的。

對稱加密的優點在於加密、解密效率通常比較高。缺點在於，資料傳送方、資料接收方需要協商、共享同一把金鑰，並確保金鑰不洩露給其他人。此外，對於多個有資料交換需求的個體，兩兩之間需要分配並維護一把金鑰，這個帶來的成本基本是不可接受的。

非對稱加密

非對稱加密的意思就是，加密資料用的金鑰（公鑰），跟解密資料用的金鑰（私鑰）是不一樣的。

什麼叫做公鑰呢？其實就是字面上的意思——公開的金鑰，誰都可以查到。因此非對稱加密也叫做公開金鑰加密。

相對應的，私鑰就是非公開的金鑰，一般是由網站的管理員持有。

公鑰、私鑰兩個有什麼聯絡呢？

簡單的說就是，通過公鑰加密的資料，只能通過私鑰解開。通過私鑰加密的資料，只能通過公鑰解開。

很多同學都知道用私鑰能解開公鑰加密的資料，但忽略了一點，私鑰加密的資料，同樣可以用公鑰解密出來。而這點對於理解HTTPS的整套加密、授權體系非常關鍵。

舉個非對稱加密的例子

小明都是某知名社交網站XX的使用者，XX出於安全考慮在登陸的地方用了非對稱加密。小明在登陸介面敲入賬號、密碼，點選“登陸”。於是，瀏覽器利用公鑰對小明的賬號密碼進行了加密，並向XX傳送登陸請求。XX的登陸授權程式通過私鑰，將賬號、密碼解密，並驗證通過。之後，將小明的個人資訊（含隱私），通過私鑰加密後，傳輸回瀏覽器。瀏覽器通過公鑰解密資料，並展示給小明。

• 步驟一： 小明輸入賬號密碼 --> 瀏覽器用公鑰加密 --> 請求傳送給XX
• 步驟二： XX用私鑰解密，驗證通過 --> 獲取小明社交資料，用私鑰加密 --> 瀏覽器用公鑰解密資料，並展示。

用非對稱加密，就能解決資料傳輸安全的問題了嗎？前面特意強調了一下，私鑰加密的資料，公鑰是可以解開的，而公鑰又是加密的。也就是說，非對稱加密只能保證單向資料傳輸的安全性。

此外，還有公鑰如何分發/獲取的問題。下面會對這兩個問題進行進一步的探討。

公開金鑰加密：兩個明顯的問題

前面舉了小明登陸社交網站XX的例子，並提到，單純使用公開金鑰加密存在兩個比較明顯的問題。

問題一：公鑰如何獲取

瀏覽器是怎麼獲得XX的公鑰的？當然，小明可以自己去網上查，XX也可以將公鑰貼在自己的主頁。然而，對於一個動不動就成敗上千萬的社交網站來說，會給使用者造成極大的不便利，畢竟大部分使用者都不知道“公鑰”是什麼東西。

問題二：資料傳輸僅單向安全

前面提到，公鑰加密的資料，只有私鑰能解開，於是小明的賬號、密碼是安全了，半路不怕被攔截。

然後有個很大的問題：私鑰加密的資料，公鑰也能解開。加上公鑰是公開的，小明的隱私資料相當於在網上換了種方式裸奔。（中間代理伺服器拿到了公鑰後，毫不猶豫的就可以解密小明的資料）

下面就分別針對這兩個問題進行解答。

問題一：公鑰如何獲取

這裡要涉及兩個非常重要的概念：證書、CA（證書頒發機構）。

證書

可以暫時把它理解為網站的身份證。這個身份證裡包含了很多資訊，其中就包含了上面提到的公鑰。

也就是說，當小明、小王、小光等使用者訪問XX的時候，再也不用滿世界的找XX的公鑰了。當他們訪問XX的時候，XX就會把證書發給瀏覽器，告訴他們說，乖，用這個裡面的公鑰加密資料。

這裡有個問題，所謂的“證書”是哪來的？這就是下面要提到的CA負責的活了。

注：相關網站建設技巧閱讀請移步到建站教程頻道。

CA（證書頒發機構）

強調兩點：

1. 可以頒發證書的CA有很多（國內外都有）。
2. 只有少數CA被認為是權威、公正的，這些CA頒發的證書，瀏覽器才認為是信得過的。比如VeriSign。（CA自己偽造證書的事情也不是沒發生過。。。）

證書頒發的細節這裡先不展開，可以先簡單理解為，網站向CA提交了申請，CA稽核通過後，將證書頒發給網站，使用者訪問網站的時候，網站將證書給到使用者。

至於證書的細節，同樣在後面講到。

上面提到，通過私鑰加密的資料，可以用公鑰解密還原。那麼，這是不是就意味著，網站傳給使用者的資料是不安全的？

答案是：是！！！（三個歎號表示強調的三次方）

看到這裡，可能你心裡會有這樣想：用了HTTPS，資料還是裸奔，這麼不靠譜，還不如直接用HTTP來的省事。

但是，為什麼業界對網站HTTPS化的呼聲越來越高呢？這明顯跟我們的感性認識相違背啊。

因為：HTTPS雖然用到了公開金鑰加密，但同時也結合了其他手段，如對稱加密，來確保授權、加密傳輸的效率、安全性。

概括來說，整個簡化的加密通訊的流程就是：

1. 小明訪問XX，XX將自己的證書給到小明（其實是給到瀏覽器，小明不會有感知）
2. 瀏覽器從證書中拿到XX的公鑰A
3. 瀏覽器生成一個只有自己自己的對稱金鑰B，用公鑰A加密，並傳給XX（其實是有協商的過程，這裡為了便於理解先簡化）
4. XX通過私鑰解密，拿到對稱金鑰B
5. 瀏覽器、XX 之後的資料通訊，都用金鑰B進行加密

注意：對於每個訪問XX的使用者，生成的對稱金鑰B理論上來說都是不一樣的。比如小明、小王、小光，可能生成的就是B1、B2、B3.

參考下圖：（附上原圖出處）

證書可能存在哪些問題

瞭解了HTTPS加密通訊的流程後，對於資料裸奔的疑慮應該基本打消了。然而，細心的觀眾可能又有疑問了：怎麼樣確保證書有合法有效的？

證書非法可能有兩種情況：

1. 證書是偽造的：壓根不是CA頒發的
2. 證書被篡改過：比如將XX網站的公鑰給替換了

舉個例子：

我們知道，這個世界上存在一種東西叫做代理，於是，上面小明登陸XX網站有可能是這樣的，小明的登陸請求先到了代理伺服器，代理伺服器再將請求轉發到的授權伺服器。

小明 --> 邪惡的代理伺服器 --> 登陸授權伺服器

小明 <-- 邪惡的代理伺服器 <-- 登陸授權伺服器

然後，這個世界壞人太多了，某一天，代理伺服器動了壞心思（也有可能是被入侵），將小明的請求攔截了。同時，返回了一個非法的證書。

小明 --> 邪惡的代理伺服器 --x--> 登陸授權伺服器

小明 <-- 邪惡的代理伺服器 --x--> 登陸授權伺服器

如果善良的小明相信了這個證書，那他就再次裸奔了。當然不能這樣，那麼，是通過什麼機制來防止這種事情的放生的呢。

下面，我們先來看看”證書”有哪些內容，然後就可以大致猜到是如何進行預防的了。

證書簡介

在正式介紹證書的格式前，先插播個小廣告，科普下數字簽名和摘要，然後再對證書進行非深入的介紹。

為什麼呢？因為數字簽名、摘要是證書防偽非常關鍵的武器。

數字簽名與摘要

簡單的來說，“摘要”就是對傳輸的內容，通過hash演算法計算出一段固定長度的串（是不是聯想到了文章摘要）。然後，在通過CA的私鑰對這段摘要進行加密，加密後得到的結果就是“數字簽名”。（這裡提到CA的私鑰，後面再進行介紹）

明文 --> hash運算 --> 摘要 --> 私鑰加密 --> 數字簽名

結合上面內容，我們知道，這段數字簽名只有CA的公鑰才能夠解密。

接下來，我們再來看看神祕的“證書”究竟包含了什麼內容，然後就大致猜到是如何對非法證書進行預防的了。

數字簽名、摘要進一步瞭解可參考 這篇文章。

證書格式

先無恥的貼上一大段內容，證書格式來自這篇不錯的文章《OpenSSL 與 SSL 數字證書概念貼》

內容非常多，這裡我們需要關注的有幾個點：

1. 證書包含了頒發證書的機構的名字 -- CA
2. 證書內容本身的數字簽名（用CA私鑰加密）
3. 證書持有者的公鑰
4. 證書籤名用到的hash演算法

此外，有一點需要補充下，就是：

1. CA本身有自己的證書，江湖人稱“根證書”。這個“根證書”是用來證明CA的身份的，本質是一份普通的數字證書。
2. 瀏覽器通常會內建大多數主流權威CA的根證書。

證書格式

1. 證書版本號(Version)版本號指明X.509證書的格式版本，現在的值可以為: 1) 0: v1 2) 1: v2 3) 2: v3也為將來的版本進行了預定義2. 證書序列號(Serial Number)序列號指定由CA分配給證書的唯一的"數字型識別符號"。當證書被取消時，實際上是將此證書的序列號放入由CA簽發的CRL中，這也是序列號唯一的原因。3. 簽名演算法識別符號(Signature Algorithm)簽名演算法標識用來指定由CA簽發證書時所使用的"簽名演算法"。演算法識別符號用來指定CA簽發證書時所使用的: 1) 公開金鑰演算法 2) hash演算法example: sha256WithRSAEncryption須向國際知名標準組織(如ISO)註冊4. 簽發機構名(Issuer)此域用來標識簽發證書的CA的X.500 DN(DN-Distinguished Name)名字。包括: 1) 國家(C) 2) 省市(ST) 3) 地區(L) 4) 組織機構(O) 5) 單位部門(OU) 6) 通用名(CN) 7) 郵箱地址5. 有效期(Validity)指定證書的有效期，包括: 1) 證書開始生效的日期時間 2) 證書失效的日期和時間每次使用證書時，需要檢查證書是否在有效期內。6. 證書使用者名稱(Subject)指定證書持有者的X.500唯一名字。包括: 1) 國家(C) 2) 省市(ST) 3) 地區(L) 4) 組織機構(O) 5) 單位部門(OU) 6) 通用名(CN) 7) 郵箱地址7. 證書持有者公開金鑰資訊(Subject Public Key Info)證書持有者公開金鑰資訊域包含兩個重要資訊: 1) 證書持有者的公開金鑰的值 2) 公開金鑰使用的演算法識別符號。此識別符號包含公開金鑰演算法和hash演算法。8. 擴充套件項(extension)X.509 V3證書是在v2的基礎上一標準形式或普通形式增加了擴充套件項，以使證書能夠附帶額外資訊。標準擴充套件是指由X.509 V3版本定義的對V2版本增加的具有廣泛應用前景的擴充套件項，任何人都可以向一些權威機構，如ISO，來註冊一些其他擴充套件，如果這些擴充套件項應用廣泛，也許以後會成為標準擴充套件項。9. 簽發者唯一識別符號(Issuer Unique Identifier)簽發者唯一識別符號在第2版加入證書定義中。此域用在當同一個X.500名字用於多個認證機構時，用一位元字串來唯一標識簽發者的X.500名字。可選。10. 證書持有者唯一識別符號(Subject Unique Identifier)持有證書者唯一識別符號在第2版的標準中加入X.509證書定義。此域用在當同一個X.500名字用於多個證書持有者時，用一位元字串來唯一標識證書持有者的X.500名字。可選。11. 簽名演算法(Signature Algorithm)證書籤發機構對證書上述內容的簽名演算法example: sha256WithRSAEncryption12. 簽名值(Issuer's Signature)證書籤發機構對證書上述內容的簽名值

如何辨別非法證書

上面提到，XX證書包含了如下內容：

瀏覽器內建的CA的根證書包含了如下關鍵內容：

好了，接下來針對之前提到的兩種非法證書的場景，講解下怎麼識別

完全偽造的證書

這種情況比較簡單，對證書進行檢查：

1. 證書頒發的機構是偽造的：瀏覽器不認識，直接認為是危險證書
2. 證書頒發的機構是確實存在的，於是根據CA名，找到對應內建的CA根證書、CA的公鑰。
3. 用CA的公鑰，對偽造的證書的摘要進行解密，發現解不了。認為是危險證書

篡改過的證書

假設代理通過某種途徑，拿到XX的證書，然後將證書的公鑰偷偷修改成自己的，然後喜滋滋的認為使用者要上鉤了。然而太單純了：

1. 檢查證書，根據CA名，找到對應的CA根證書，以及CA的公鑰。
2. 用CA的公鑰，對證書的數字簽名進行解密，得到對應的證書摘要AA
3. 根據證書籤名使用的hash演算法，計算出當前證書的摘要BB
4. 對比AA跟BB，發現不一致--> 判定是危險證書

HTTPS握手流程

上面囉囉嗦嗦講了一大通，HTTPS如何確保資料加密傳輸的安全的機制基本都覆蓋到了，太過技術細節的就直接跳過了。

最後還有最後兩個問題：

1. 網站是怎麼把證書給到使用者（瀏覽器）的
2. 上面提到的對稱金鑰是怎麼協商出來的

上面兩個問題，其實就是HTTPS握手階段要乾的事情。HTTPS的資料傳輸流程整體上跟HTTP是類似的，同樣包含兩個階段：握手、資料傳輸。

1. 握手：證書下發，金鑰協商（這個階段都是明文的）
2. 資料傳輸：這個階段才是加密的，用的就是握手階段協商出來的對稱金鑰

阮老師的文章寫的非常不錯，通俗易懂，感興趣的同學可以看下。

附：《SSL/TLS協議執行機制的概述》：http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html