HTTPS科普掃盲帖

時間 2019-11-05

標籤 https 科普掃盲简体版

原文原文鏈接

爲何須要HTTPS

HTTP是明文傳輸的，也就意味着，介於發送端、接收端中間的任意節點均可以知道大家傳輸的內容是什麼。這些節點多是路由器、代理等。html

舉個最多見的例子，用戶登錄。用戶輸入帳號，密碼，採用HTTP的話，只要在代理服務器上作點手腳就能夠拿到你的密碼了。算法

用戶登錄 --> 代理服務器（作手腳）--> 實際受權服務器瀏覽器

在發送端對密碼進行加密？沒用的，雖然別人不知道你原始密碼是多少，但可以拿到加密後的帳號密碼，照樣能登錄。安全

HTTPS是如何保障安全的

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

HTTP --> TCP （明文傳輸）網絡

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

神馬是TLS/SSL？ui

通俗的講，TLS、SSL實際上是相似的東西，SSL是個加密套件，負責對HTTP的數據進行加密。TLS是SSL的升級版。如今提到HTTPS，加密套件基本指的是TLS。加密

傳輸加密的流程spa

原先是應用層將數據直接給到TCP進行傳輸，如今改爲應用層將數據給到TLS/SSL，將數據加密後，再給到TCP進行傳輸。

大體如圖所示。

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

HTTPS是如何加密數據的

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

對稱加密

對稱加密的意思就是，加密數據用的密鑰，跟解密數據用的密鑰是同樣的。

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

非對稱加密

非對稱加密的意思就是，加密數據用的密鑰（公鑰），跟解密數據用的密鑰（私鑰）是不同的。

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

相對應的，私鑰就是非公開的密鑰，通常是由網站的管理員持有。

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

簡單的說就是，經過公鑰加密的數據，只能經過私鑰解開。經過私鑰加密的數據，只能經過公鑰解開。

不少同窗都知道用私鑰能解開公鑰加密的數據，但忽略了一點，私鑰加密的數據，一樣能夠用公鑰解密出來。而這點對於理解HTTPS的整套加密、受權體系很是關鍵。

舉個非對稱加密的例子

登錄用戶：小明
受權網站：某知名社交網站（如下簡稱XX）

小明都是某知名社交網站XX的用戶，XX出於安全考慮在登錄的地方用了非對稱加密。小明在登錄界面敲入帳號、密碼，點擊「登錄」。因而，瀏覽器利用公鑰對小明的帳號密碼進行了加密，並向XX發送登錄請求。XX的登錄受權程序經過私鑰，將帳號、密碼解密，並驗證經過。以後，將小明的我的信息（含隱私），經過私鑰加密後，傳輸回瀏覽器。瀏覽器經過公鑰解密數據，並展現給小明。

步驟一：小明輸入帳號密碼 --> 瀏覽器用公鑰加密 --> 請求發送給XX
步驟二： XX用私鑰解密，驗證經過 --> 獲取小明社交數據，用私鑰加密 --> 瀏覽器用公鑰解密數據，並展現。

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

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

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

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

公鑰如何獲取
數據傳輸僅單向安全

問題一：公鑰如何獲取

瀏覽器是怎麼得到XX的公鑰的？固然，小明能夠本身去網上查，XX也能夠將公鑰貼在本身的主頁。然而，對於一個動不動就成敗上千萬的社交網站來講，會給用戶形成極大的不便利，畢竟大部分用戶都不知道「公鑰」是什麼東西。

問題二：數據傳輸僅單向安全

前面提到，公鑰加密的數據，只有私鑰能解開，因而小明的帳號、密碼是安全了，半路不怕被攔截。

而後有個很大的問題：私鑰加密的數據，公鑰也能解開。加上公鑰是公開的，小明的隱私數據至關於在網上換了種方式裸奔。（中間代理服務器拿到了公鑰後，絕不猶豫的就能夠解密小明的數據）

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

問題一：公鑰如何獲取

這裏要涉及兩個很是重要的概念：證書、CA（證書頒發機構）。

證書

能夠暫時把它理解爲網站的身份證。這個身份證裏包含了不少信息，其中就包含了上面提到的公鑰。

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

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

CA（證書頒發機構）

強調兩點：

能夠頒發證書的CA有不少（國內外都有）。
只有少數CA被認爲是權威、公正的，這些CA頒發的證書，瀏覽器才認爲是信得過的。好比VeriSign。（CA本身僞造證書的事情也不是沒發生過。。。）

證書頒發的細節這裏先不展開，能夠先簡單理解爲，網站向CA提交了申請，CA審覈經過後，將證書頒發給網站，用戶訪問網站的時候，網站將證書給到用戶。

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

問題二：數據傳輸僅單向安全

上面提到，經過私鑰加密的數據，能夠用公鑰解密還原。那麼，這是否是就意味着，網站傳給用戶的數據是不安全的？

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

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

可是，爲何業界對網站HTTPS化的呼聲愈來愈高呢？這明顯跟咱們的感性認識相違背啊。

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

歸納來講，整個簡化的加密通訊的流程就是：

小明訪問XX，XX將本身的證書給到小明（實際上是給到瀏覽器，小明不會有感知）
瀏覽器從證書中拿到XX的公鑰A
瀏覽器生成一個只有本身知道的對稱密鑰B，用公鑰A加密，並傳給XX（實際上是有協商的過程，這裏爲了便於理解先簡化）
XX經過私鑰解密，拿到對稱密鑰B
瀏覽器、XX 以後的數據通訊，都用密鑰B進行加密

注意：對於每一個訪問XX的用戶，生成的對稱密鑰B理論上來講都是不同的。好比小明、小王、小光，可能生成的就是B一、B二、B3.

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

證書可能存在哪些問題

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

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

證書是僞造的：壓根不是CA頒發的
證書被篡改過：好比將XX網站的公鑰給替換了

舉個例子：

咱們知道，這個世界上存在一種東西叫作代理，因而，上面小明登錄XX網站有多是這樣的，小明的登錄請求先到了代理服務器，代理服務器再將請求轉發到的受權服務器。

小明 --> 邪惡的代理服務器 --> 登錄受權服務器

小明 <-- 邪惡的代理服務器 <-- 登錄受權服務器

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

小明 --> 邪惡的代理服務器 --x--> 登錄受權服務器

小明 <-- 邪惡的代理服務器 --x--> 登錄受權服務器

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

下面，咱們先來看看」證書」有哪些內容，而後就能夠大體猜到是如何進行預防的了。

證書簡介

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

爲何呢？由於數字簽名、摘要是證書防僞很是關鍵的武器。

數字簽名與摘要

簡單的來講，「摘要」就是對傳輸的內容，經過hash算法計算出一段固定長度的串（是否是聯想到了文章摘要）。而後，在經過CA的私鑰對這段摘要進行加密，加密後獲得的結果就是「數字簽名」。（這裏提到CA的私鑰，後面再進行介紹）

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

結合上面內容，咱們知道，這段數字簽名只有CA的公鑰纔可以解密。

接下來，咱們再來看看神祕的「證書」究竟包含了什麼內容，而後就大體猜到是如何對非法證書進行預防的了。

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

證書格式

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

內容很是多，這裏咱們須要關注的有幾個點：

證書包含了頒發證書的機構的名字 -- CA
證書內容自己的數字簽名（用CA私鑰加密）
證書持有者的公鑰
證書籤名用到的hash算法

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

CA自己有本身的證書，江湖人稱「根證書」。這個「根證書」是用來證實CA的身份的，本質是一份普通的數字證書。
瀏覽器一般會內置大多數主流權威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: sha256WithRSAEncryption

12. 簽名值(Issuer's Signature)
證書籤發機構對證書上述內容的簽名值