為什么需要HTTPS

HTTP是明文傳輸?shù)模簿鸵馕吨?，介于發(fā)送端、接收端中間的任意節(jié)點都可以知道你們傳輸?shù)膬?nèi)容是什么。這些節(jié)點可能是路由器、代理等。

舉個最常見的例子，用戶登陸。用戶輸入賬號，密碼，采用HTTP的話，只要在代理服務(wù)器上做點手腳就可以拿到你的密碼了。 

用戶登陸 --> 代理服務(wù)器（做手腳）--> 實際授權(quán)服務(wù)器

在發(fā)送端對密碼進(jìn)行加密？沒用的，雖然別人不知道你原始密碼是多少，但能夠拿到加密后的賬號密碼，照樣能登陸。

HTTPS是如何保障安全的

HTTPS其實就是secure http的意思啦，也就是HTTP的安全升級版。稍微了解網(wǎng)絡(luò)基礎(chǔ)的同學(xué)都知道，HTTP是應(yīng)用層協(xié)議，位于HTTP協(xié)議之下是傳輸協(xié)議TCP。TCP負(fù)責(zé)傳輸，HTTP則定義了數(shù)據(jù)如何進(jìn)行包裝。 

HTTP --> TCP （明文傳輸）

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

神馬是TLS/SSL？

通俗的講，TLS、SSL其實是類似的東西，SSL是個加密套件，負(fù)責(zé)對HTTP的數(shù)據(jù)進(jìn)行加密。TLS是SSL的升級版?，F(xiàn)在提到HTTPS，加密套件基本指的是TLS。

傳輸加密的流程

原先是應(yīng)用層將數(shù)據(jù)直接給到TCP進(jìn)行傳輸，現(xiàn)在改成應(yīng)用層將數(shù)據(jù)給到TLS/SSL，將數(shù)據(jù)加密后，再給到TCP進(jìn)行傳輸。

大致如圖所示。

就是這么回事。將數(shù)據(jù)加密后再傳輸，而不是任由數(shù)據(jù)在復(fù)雜而又充滿危險的網(wǎng)絡(luò)上明文裸奔，在很大程度上確保了數(shù)據(jù)的安全。這樣的話，即使數(shù)據(jù)被中間節(jié)點截獲，壞人也看不懂。

HTTPS是如何加密數(shù)據(jù)的

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

對稱加密

對稱加密的意思就是，加密數(shù)據(jù)用的密鑰，跟解密數(shù)據(jù)用的密鑰是一樣的。

對稱加密的優(yōu)點在于加密、解密效率通常比較高。缺點在于，數(shù)據(jù)發(fā)送方、數(shù)據(jù)接收方需要協(xié)商、共享同一把密鑰，并確保密鑰不泄露給其他人。此外，對于多個有數(shù)據(jù)交換需求的個體，兩兩之間需要分配并維護(hù)一把密鑰，這個帶來的成本基本是不可接受的。

非對稱加密

非對稱加密的意思就是，加密數(shù)據(jù)用的密鑰（公鑰），跟解密數(shù)據(jù)用的密鑰（私鑰）是不一樣的。

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

相對應(yīng)的，私鑰就是非公開的密鑰，一般是由網(wǎng)站的管理員持有。

公鑰、私鑰兩個有什么聯(lián)系呢？

簡單的說就是，通過公鑰加密的數(shù)據(jù)，只能通過私鑰解開。通過私鑰加密的數(shù)據(jù)，只能通過公鑰解開。

很多同學(xué)都知道用私鑰能解開公鑰加密的數(shù)據(jù)，但忽略了一點，私鑰加密的數(shù)據(jù)，同樣可以用公鑰解密出來。而這點對于理解HTTPS的整套加密、授權(quán)體系非常關(guān)鍵。

舉個非對稱加密的例子

• 登陸用戶：小明
• 授權(quán)網(wǎng)站：某知名社交網(wǎng)站（以下簡稱XX）

小明都是某知名社交網(wǎng)站XX的用戶，XX出于安全考慮在登陸的地方用了非對稱加密。小明在登陸界面敲入賬號、密碼，點擊“登陸”。于是，瀏覽器利用公鑰對小明的賬號密碼進(jìn)行了加密，并向XX發(fā)送登陸請求。XX的登陸授權(quán)程序通過私鑰，將賬號、密碼解密，并驗證通過。之后，將小明的個人信息（含隱私），通過私鑰加密后，傳輸回瀏覽器。瀏覽器通過公鑰解密數(shù)據(jù)，并展示給小明。

• 步驟一： 小明輸入賬號密碼 --> 瀏覽器用公鑰加密 --> 請求發(fā)送給XX
• 步驟二： XX用私鑰解密，驗證通過 --> 獲取小明社交數(shù)據(jù)，用私鑰加密 --> 瀏覽器用公鑰解密數(shù)據(jù)，并展示。

用非對稱加密，就能解決數(shù)據(jù)傳輸安全的問題了嗎？前面特意強(qiáng)調(diào)了一下，私鑰加密的數(shù)據(jù)，公鑰是可以解開的，而公鑰又是加密的。也就是說，非對稱加密只能保證單向數(shù)據(jù)傳輸?shù)陌踩浴?/p>

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

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

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

1. 公鑰如何獲取
2. 數(shù)據(jù)傳輸僅單向安全

問題一：公鑰如何獲取

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

問題二：數(shù)據(jù)傳輸僅單向安全

前面提到，公鑰加密的數(shù)據(jù)，只有私鑰能解開，于是小明的賬號、密碼是安全了，半路不怕被攔截。

然后有個很大的問題：私鑰加密的數(shù)據(jù)，公鑰也能解開。加上公鑰是公開的，小明的隱私數(shù)據(jù)相當(dāng)于在網(wǎng)上換了種方式裸奔。（中間代理服務(wù)器拿到了公鑰后，毫不猶豫的就可以解密小明的數(shù)據(jù)）

下面就分別針對這兩個問題進(jìn)行解答。

問題一：公鑰如何獲取

這里要涉及兩個非常重要的概念：證書、CA（證書頒發(fā)機(jī)構(gòu)）。

證書

可以暫時把它理解為網(wǎng)站的身份證。這個身份證里包含了很多信息，其中就包含了上面提到的公鑰。

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

這里有個問題，所謂的“證書”是哪來的？這就是下面要提到的CA負(fù)責(zé)的活了。

CA（證書頒發(fā)機(jī)構(gòu)）

強(qiáng)調(diào)兩點：

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

證書頒發(fā)的細(xì)節(jié)這里先不展開，可以先簡單理解為，網(wǎng)站向CA提交了申請，CA審核通過后，將證書頒發(fā)給網(wǎng)站，用戶訪問網(wǎng)站的時候，網(wǎng)站將證書給到用戶。

至于證書的細(xì)節(jié)，同樣在后面講到。

問題二：數(shù)據(jù)傳輸僅單向安全

上面提到，通過私鑰加密的數(shù)據(jù)，可以用公鑰解密還原。那么，這是不是就意味著，網(wǎng)站傳給用戶的數(shù)據(jù)是不安全的？

答案是：是?。。。ㄈ齻€嘆號表示強(qiáng)調(diào)的三次方）

看到這里，可能你心里會有這樣想：用了HTTPS，數(shù)據(jù)還是裸奔，這么不靠譜，還不如直接用HTTP來的省事。

但是，為什么業(yè)界對網(wǎng)站HTTPS化的呼聲越來越高呢？這明顯跟我們的感性認(rèn)識相違背啊。

因為：HTTPS雖然用到了公開密鑰加密，但同時也結(jié)合了其他手段，如對稱加密，來確保授權(quán)、加密傳輸?shù)男?、安全性?/p>

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

• 小明訪問XX，XX將自己的證書給到小明（其實是給到瀏覽器，小明不會有感知）
• 瀏覽器從證書中拿到XX的公鑰A
• 瀏覽器生成一個只有自己自己的對稱密鑰B，用公鑰A加密，并傳給XX（其實是有協(xié)商的過程，這里為了便于理解先簡化）
• XX通過私鑰解密，拿到對稱密鑰B
• 瀏覽器、XX 之后的數(shù)據(jù)通信，都用密鑰B進(jìn)行加密

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

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

證書可能存在哪些問題

了解了HTTPS加密通信的流程后，對于數(shù)據(jù)裸奔的疑慮應(yīng)該基本打消了。然而，細(xì)心的觀眾可能又有疑問了：怎么樣確保證書有合法有效的？

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

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

舉個例子：

我們知道，這個世界上存在一種東西叫做代理，于是，上面小明登陸XX網(wǎng)站有可能是這樣的，小明的登陸請求先到了代理服務(wù)器，代理服務(wù)器再將請求轉(zhuǎn)發(fā)到的授權(quán)服務(wù)器。 

小明 --> 邪惡的代理服務(wù)器 --> 登陸授權(quán)服務(wù)器
小明 <-- 邪惡的代理服務(wù)器 <-- 登陸授權(quán)服務(wù)器

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

小明 --> 邪惡的代理服務(wù)器 --x--> 登陸授權(quán)服務(wù)器
小明 <-- 邪惡的代理服務(wù)器 --x--> 登陸授權(quán)服務(wù)器

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

下面，我們先來看看”證書”有哪些內(nèi)容，然后就可以大致猜到是如何進(jìn)行預(yù)防的了。

證書簡介

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

為什么呢？因為數(shù)字簽名、摘要是證書防偽非常關(guān)鍵的武器。

數(shù)字簽名與摘要

簡單的來說，“摘要”就是對傳輸?shù)膬?nèi)容，通過hash算法計算出一段固定長度的串（是不是聯(lián)想到了文章摘要）。然后，在通過CA的私鑰對這段摘要進(jìn)行加密，加密后得到的結(jié)果就是“數(shù)字簽名”。（這里提到CA的私鑰，后面再進(jìn)行介紹） 

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

結(jié)合上面內(nèi)容，我們知道，這段數(shù)字簽名只有CA的公鑰才能夠解密。

接下來，我們再來看看神秘的“證書”究竟包含了什么內(nèi)容，然后就大致猜到是如何對非法證書進(jìn)行預(yù)防的了。

數(shù)字簽名、摘要進(jìn)一步了解可參考 這篇文章。

證書格式

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

內(nèi)容非常多，這里我們需要關(guān)注的有幾個點：

1. 證書包含了頒發(fā)證書的機(jī)構(gòu)的名字 -- CA
2. 證書內(nèi)容本身的數(shù)字簽名（用CA私鑰加密）
3. 證書持有者的公鑰
4. 證書簽名用到的hash算法

此外，有一點需要補(bǔ)充下，就是：

1. CA本身有自己的證書，江湖人稱“根證書”。這個“根證書”是用來證明CA的身份的，本質(zhì)是一份普通的數(shù)字證書。
2. 瀏覽器通常會內(nèi)置大多數(shù)主流權(quán)威CA的根證書。

證書格式

1. 證書版本號(Version)

版本號指明X.509證書的格式版本，現(xiàn)在的值可以為:    

    1) 0: v1    

    2) 1: v2    

    3) 2: v3也為將來的版本進(jìn)行了預(yù)定義

2. 證書序列號(Serial Number)

序列號指定由CA分配給證書的唯一的"數(shù)字型標(biāo)識符"。當(dāng)證書被取消時，實際上是將此證書的序列號放入由CA簽發(fā)的CRL中，

這也是序列號唯一的原因。

3. 簽名算法標(biāo)識符(Signature Algorithm)

簽名算法標(biāo)識用來指定由CA簽發(fā)證書時所使用的"簽名算法"。算法標(biāo)識符用來指定CA簽發(fā)證書時所使用的:    

    1) 公開密鑰算法    

    2) hash算法example: sha256WithRSAEncryption

須向國際知名標(biāo)準(zhǔn)組織(如ISO)注冊

4. 簽發(fā)機(jī)構(gòu)名(Issuer)

此域用來標(biāo)識簽發(fā)證書的CA的X.500 DN(DN-Distinguished Name)名字。包括:    

    1) 國家(C)    

    2) 省市(ST)    

    3) 地區(qū)(L)    

    4) 組織機(jī)構(gòu)(O)    

    5) 單位部門(OU)    

    6) 通用名(CN)    

    7) 郵箱地址    

5. 有效期(Validity)

指定證書的有效期，包括:    

    1) 證書開始生效的日期時間    

    2) 證書失效的日期和時間每次使用證書時，需要檢查證書是否在有效期內(nèi)。

6. 證書用戶名(Subject)

指定證書持有者的X.500唯一名字。包括:    

    1) 國家(C)    

    2) 省市(ST)    

    3) 地區(qū)(L)    

    4) 組織機(jī)構(gòu)(O)    

    5) 單位部門(OU)    

    6) 通用名(CN)    

    7) 郵箱地址    

7. 證書持有者公開密鑰信息(Subject Public Key Info)

證書持有者公開密鑰信息域包含兩個重要信息:    

    1) 證書持有者的公開密鑰的值    

    2) 公開密鑰使用的算法標(biāo)識符。此標(biāo)識符包含公開密鑰算法和hash算法。    

8. 擴(kuò)展項(extension)

X.509 V3證書是在v2的基礎(chǔ)上一標(biāo)準(zhǔn)形式或普通形式增加了擴(kuò)展項，以使證書能夠附帶額外信息。標(biāo)準(zhǔn)擴(kuò)展是指由X.509 V3版本定義的對V2版本增加的具有廣泛應(yīng)用前景的擴(kuò)展項，任何人都可以向一些權(quán)威機(jī)構(gòu)，如ISO，來注冊一些其他擴(kuò)展，如果這些擴(kuò)展項應(yīng)用廣泛，也許以后會成為標(biāo)準(zhǔn)擴(kuò)展項。

9. 簽發(fā)者唯一標(biāo)識符(Issuer Unique Identifier)

簽發(fā)者唯一標(biāo)識符在第2版加入證書定義中。此域用在當(dāng)同一個X.500名字用于多個認(rèn)證機(jī)構(gòu)時，用一比特字符串來唯一標(biāo)識簽發(fā)者的X.500名字?？蛇x。

10. 證書持有者唯一標(biāo)識符(Subject Unique Identifier)

持有證書者唯一標(biāo)識符在第2版的標(biāo)準(zhǔn)中加入X.509證書定義。此域用在當(dāng)同一個X.500名字用于多個證書持有者時，用一比特字符串來唯一標(biāo)識證書持有者的X.500名字?？蛇x。

11. 簽名算法(Signature Algorithm)

證書簽發(fā)機(jī)構(gòu)對證書上述內(nèi)容的簽名算法

example: sha256WithRSAEncryption

12. 簽名值(Issuer's Signature)

證書簽發(fā)機(jī)構(gòu)對證書上述內(nèi)容的簽名值

如何辨別非法證書

上面提到，XX證書包含了如下內(nèi)容：

1. 證書包含了頒發(fā)證書的機(jī)構(gòu)的名字 -- CA
2. 證書內(nèi)容本身的數(shù)字簽名（用CA私鑰加密）
3. 證書持有者的公鑰
4. 證書簽名用到的hash算法

瀏覽器內(nèi)置的CA的根證書包含了如下關(guān)鍵內(nèi)容：

CA的公鑰（非常重要?。。。?/p>

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

完全偽造的證書

這種情況比較簡單，對證書進(jìn)行檢查：

1. 證書頒發(fā)的機(jī)構(gòu)是偽造的：瀏覽器不認(rèn)識，直接認(rèn)為是危險證書
2. 證書頒發(fā)的機(jī)構(gòu)是確實存在的，于是根據(jù)CA名，找到對應(yīng)內(nèi)置的CA根證書、CA的公鑰。
3. 用CA的公鑰，對偽造的證書的摘要進(jìn)行解密，發(fā)現(xiàn)解不了。認(rèn)為是危險證書

篡改過的證書

假設(shè)代理通過某種途徑，拿到XX的證書，然后將證書的公鑰偷偷修改成自己的，然后喜滋滋的認(rèn)為用戶要上鉤了。然而太單純了：

1. 檢查證書，根據(jù)CA名，找到對應(yīng)的CA根證書，以及CA的公鑰。
2. 用CA的公鑰，對證書的數(shù)字簽名進(jìn)行解密，得到對應(yīng)的證書摘要AA
3. 根據(jù)證書簽名使用的hash算法，計算出當(dāng)前證書的摘要BB
4. 對比AA跟BB，發(fā)現(xiàn)不一致--> 判定是危險證書

HTTPS握手流程

上面啰啰嗦嗦講了一大通，HTTPS如何確保數(shù)據(jù)加密傳輸?shù)陌踩臋C(jī)制基本都覆蓋到了，太過技術(shù)細(xì)節(jié)的就直接跳過了。

最后還有最后兩個問題：

1. 網(wǎng)站是怎么把證書給到用戶（瀏覽器）的
2. 上面提到的對稱密鑰是怎么協(xié)商出來的

上面兩個問題，其實就是HTTPS握手階段要干的事情。HTTPS的數(shù)據(jù)傳輸流程整體上跟HTTP是類似的，同樣包含兩個階段：握手、數(shù)據(jù)傳輸。

1. 握手：證書下發(fā)，密鑰協(xié)商（這個階段都是明文的）
2. 數(shù)據(jù)傳輸：這個階段才是加密的，用的就是握手階段協(xié)商出來的對稱密鑰

作者：程序猿小卡

原文：http://www.cnblogs.com/chyingp/p/https-introduction.html#undefined