1、HTTPS 協(xié)議簡(jiǎn)介

Https 協(xié)議是由SSL HTTP 協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，相比

Http 更加安全。相比Http 有如下特點(diǎn)：

（1）Https 需要到CA 申請(qǐng)證書(shū)，一般是收費(fèi)的；

（2）Http 是超文本傳輸協(xié)議，信息是明文傳輸，Https 則是具有安全性的SSL 加密傳
輸協(xié)議；

（3）Http 一般使用的端口是80 端口，Https 一般使用443 端口。

Https 的核心作用：

（1）數(shù)據(jù)保密性：保證內(nèi)容在傳輸過(guò)程不會(huì)被第三方看到；

（2）數(shù)據(jù)完整性：保證內(nèi)容在傳輸過(guò)程中不會(huì)被篡改；

（3）身份校驗(yàn)：保證數(shù)據(jù)到達(dá)用戶期望的目的地；

2、HTTPS 協(xié)議流程

與 HTTP 相比，HTTPS 增加了SSL（Secure Sockets Layer）安全套接層，如圖1 所示。

圖1、安全套接層

在真正的數(shù)據(jù)交互之前通過(guò) SSL Handshake（SSL 握手）協(xié)商一個(gè)對(duì)稱秘鑰，通過(guò)這個(gè)

對(duì)稱秘鑰對(duì)以后的通信內(nèi)容進(jìn)行加密。如圖2 所示，HTTPS 的通信過(guò)程如下：

（1）、客戶端發(fā)起HTTPS 請(qǐng)求
（2）、服務(wù)端證書(shū)配置
（3）、傳送證書(shū)
（4）、客戶端解析證書(shū)
（5）、傳送加密信息
（6）、服務(wù)端解密信息
（7）、傳輸加密后的信息
（8）、客戶端解密信息

如圖 2、HTTPS 通信過(guò)程

3、SSL 證書(shū)及其驗(yàn)證過(guò)程

3.1 數(shù)字證書(shū)

數(shù)字證書(shū)在 SSL 握手過(guò)程中扮演身份認(rèn)證和密鑰分發(fā)的功能，究竟什么是數(shù)字證書(shū)呢？

簡(jiǎn)單來(lái)說(shuō)數(shù)字證書(shū)就是一種網(wǎng)絡(luò)上證明持有者身份的文件，同時(shí)證書(shū)中還含有公鑰。證書(shū)是由國(guó)際上公認(rèn)的證書(shū)機(jī)構(gòu)頒發(fā)，一些驗(yàn)證證書(shū)的客戶端應(yīng)用程序比如瀏覽器對(duì)于這些機(jī)構(gòu)頒發(fā)的證書(shū)完全信任。通常windows 部署系統(tǒng)的時(shí)候會(huì)讓客戶端安裝“根受信任機(jī)構(gòu)列表”，當(dāng)客戶端收到一個(gè)證書(shū)時(shí)會(huì)查看證書(shū)是否是該列表中的機(jī)構(gòu)頒發(fā)的，如果是則信任這個(gè)證書(shū)。

如圖3 就是一個(gè)受信任的證書(shū)樣式，而圖4 是一個(gè)不受信任的非法證書(shū)。

圖 3、合法受信任的證書(shū)

圖4、非法不受信任的證書(shū)

在服務(wù)器證書(shū)不在受信任的范圍內(nèi)的時(shí)候，瀏覽器會(huì)給出安全提示：

圖 5、瀏覽器報(bào)警

圖6、瀏覽器報(bào)警

3.2 數(shù)字證書(shū)的驗(yàn)證

由此可以看出 https 的站點(diǎn)需要一份數(shù)字證書(shū)，證書(shū)需要一個(gè)機(jī)構(gòu)頒發(fā)，這個(gè)機(jī)構(gòu)可以使一個(gè)國(guó)際上公認(rèn)的證書(shū)機(jī)構(gòu)，也可以是任何一臺(tái)安裝有證書(shū)服務(wù)的計(jì)算機(jī)?？蛻舳耸欠裥湃芜@個(gè)證書(shū)取決于客戶端上是否安裝了這個(gè)證書(shū)頒發(fā)者的根證書(shū)。證書(shū)的頒發(fā)和驗(yàn)證過(guò)程如

圖7 所示。

圖 7、證書(shū)頒發(fā)和驗(yàn)證過(guò)程

以 IE 瀏覽器為例，會(huì)從如下三個(gè)方面驗(yàn)證證書(shū)的有效性，不滿足情況下會(huì)報(bào)警提示：

（1） 證書(shū)頒發(fā)者是否在“根受信任的證書(shū)頒發(fā)機(jī)構(gòu)列表”中；

（2） 證書(shū)是否過(guò)期；

（3） 證書(shū)的持有者是否和訪問(wèn)的網(wǎng)站一致；

實(shí)際上除此之外瀏覽器還會(huì)定期證書(shū)頒發(fā)者的“證書(shū)吊銷列表”，如果某個(gè)證書(shū)雖然符合上述條件，但是被它的頒發(fā)者在“證書(shū)吊銷列表”中列出，那么也將給出警告。每個(gè)證書(shū)的CRLDistribution Point 字段顯示了查看這個(gè)列表的url。盡管如此，windows 對(duì)于這個(gè)列表是“不
敏感”的，也就是說(shuō)windows 的api 會(huì)緩存這個(gè)列表，直到設(shè)置的緩存過(guò)期才會(huì)再?gòu)腃RLDistribution Point 中下載新的列表?？梢酝ㄟ^(guò)在證書(shū)頒發(fā)服務(wù)端盡量小的設(shè)置這個(gè)有效期（最小1 天），來(lái)盡量使windows 的客戶端“敏感”。

4、HTTPS 性能消耗及其優(yōu)化

4.1 HTTPS 性能消耗

圖 8、HTTPS 通信過(guò)程

如圖 8 所示，Https 與Http 的通信過(guò)程相比存在如下幾點(diǎn)差異：

（ 1 ） 302 重定向： 302 跳轉(zhuǎn)不是每次都需要的， 當(dāng)用戶在地址欄直接輸入https://www.baidu.com（當(dāng)然可以是其他https 站點(diǎn)，只要帶上前綴https://）進(jìn)行訪問(wèn)的時(shí)候就不會(huì)有這個(gè)重定向過(guò)程；

（2）SSL 握手（SSL handshake）過(guò)程增加的網(wǎng)絡(luò)傳輸RTT，及數(shù)字簽名的校驗(yàn)過(guò)程，特別是一些移動(dòng)終端的計(jì)算性能本身不是很強(qiáng)，耗時(shí)就更加明顯；

（3）證書(shū)驗(yàn)證和狀態(tài)檢驗(yàn)，檢查證書(shū)是否過(guò)期等。瀏覽器一般會(huì)通過(guò)ocsp 來(lái)檢查證書(shū)的撤銷狀態(tài)，在拿到服務(wù)器發(fā)送過(guò)來(lái)的證書(shū)之后會(huì)請(qǐng)求ocsp 站點(diǎn)獲取證書(shū)的狀態(tài)，如果ocsp站點(diǎn)位于國(guó)外或者出現(xiàn)故障的話會(huì)影響這個(gè)正常用戶的訪問(wèn)速度。好在ocsp 檢查周期一般比較長(zhǎng)（7 天），不是很頻繁。并且有些瀏覽器直接關(guān)閉了ocsp 功能。

4.2 HTTPS 性能優(yōu)化

既然 HTTPS 相比HTTP 存在很多耗時(shí)的地方，實(shí)際測(cè)試表明沒(méi)有經(jīng)過(guò)任何優(yōu)化的情況下，HTTPS 要比HTTP 耗時(shí)多達(dá)200ms 以上，因此針對(duì)HTTPS 的性能優(yōu)化非常必要。手段都有哪些呢，下面我們來(lái)一一分析：

1、首先是減少302 跳轉(zhuǎn)，通過(guò)服務(wù)器配置HSTS（HTTP Strict Transport Security，HTTP 嚴(yán)格傳輸協(xié)議，RFC 6797）。他的作用是強(qiáng)制客戶端（如瀏覽器）使用HTTPS 與服務(wù)器之間連接。同時(shí)HSTS 還能夠抵御SSL 剝離攻擊，SSL 剝離攻擊屬于中間人劫持的一種，是由Moxie Marlinspike 于2009 年發(fā)明的一種攻擊方式，它的前提是用戶很少直接在地址欄中輸入https://，更多是通過(guò)點(diǎn)擊連接、3xx 重定向從HTTP 頁(yè)面進(jìn)入HTTPS。攻擊者在中間將所有的https://替換成http://以達(dá)到阻止HTTPS 的目的。

HSTS 的實(shí)現(xiàn)方式是當(dāng)客戶端通過(guò)https 發(fā)出請(qǐng)求時(shí)，在服務(wù)器返回的超文本傳輸協(xié)議響應(yīng)頭中包含Strict-Transport-Security 字段。非加密傳輸時(shí)設(shè)置的HSTS 字段無(wú)效，比如https://www.baidu.com/ 的響應(yīng)頭含有Strict-Transport-Security: max-age=31536000;includeSubDomains，表示在接下來(lái)的一年時(shí)間里，瀏覽器只要向www.baidu.com 發(fā)送請(qǐng)求必須采用HTTPS 方式發(fā)送。用戶在地址欄中輸入http://www.baidu.com，瀏覽器會(huì)自動(dòng)將http:替換成https://。

2、設(shè)置ocsp stapling file，使得ocsp 的請(qǐng)求不再發(fā)往ca 提供的ocsp 站點(diǎn)，改為發(fā)往網(wǎng)站的webserver。

3、啟用SPDY，SPDY（讀作“SPeeDY”）是Google 開(kāi)發(fā)的基于TCP 的應(yīng)用層協(xié)議，用以最小化網(wǎng)絡(luò)延遲，提升網(wǎng)絡(luò)速度，優(yōu)化用戶的網(wǎng)絡(luò)使用體驗(yàn)。SPDY 并不是一種用于替代HTTP 的協(xié)議，而是對(duì)HTTP 協(xié)議的增強(qiáng)。包括數(shù)據(jù)流的多路復(fù)用、請(qǐng)求優(yōu)先級(jí)以及HTTP

報(bào)頭壓縮。協(xié)議層次如圖9 所示：

圖 9、SPDY 協(xié)議位置

SPDY 協(xié)議比較復(fù)雜，這里就不再詳細(xì)展開(kāi)。使用SPDY 不僅能夠提高HTTPS 的訪問(wèn)速度，甚至比HTTP 還要快。谷歌表示，引入SPDY 協(xié)議后，在實(shí)驗(yàn)室測(cè)試中頁(yè)面加載速度比原先快64%。SPDY 的缺點(diǎn)是支持的瀏覽器不夠多，Google 也表示2016 年將從Chrome中去除SPDY，改用HTTP/2（IETF 努力打造的全新協(xié)議，前身就是大名鼎鼎的HTTP，采用了SPDY 很多的特點(diǎn)）。

4、有限ECDHE 密鑰交換算法，支持PFS（完全正向保密Perfect forward secrecy），能夠?qū)崿F(xiàn)false start；

5、啟用TFO（TCP Fast Open），TFO 能夠優(yōu)化TCP 鏈接的RTT 次數(shù)從而提高效率，不僅能夠優(yōu)化HTTPS，同時(shí)也能夠優(yōu)化HTTP，但是支持TFO 的客戶端不多；

6、設(shè)置ssl session 的共享內(nèi)存cache. 以nginx 為例，它目前只支持session cache的單機(jī)多進(jìn)程共享。

7、配置相同的session ticket key，部署在多個(gè)服務(wù)器上，這樣多個(gè)不同的服務(wù)器也能產(chǎn)生相同的 session ticket。session ticket 的缺點(diǎn)是支持率不廣，大概只有40%。而session id 是client hello 的標(biāo)準(zhǔn)內(nèi)容，從SSL2.0 開(kāi)始就被全部客戶支持。

8、設(shè)置tls record size，最好是能動(dòng)態(tài)調(diào)整record size，即連接剛建立時(shí)record size設(shè)置成msg，連接穩(wěn)定之后可以將record size 動(dòng)態(tài)增加。

5、 HTTPS 的安全分析

從上面對(duì) HTTPS 通信過(guò)程的分析，大家可以看出HTTPS 通過(guò)客戶端和服務(wù)器之間協(xié)商出來(lái)的對(duì)稱密鑰對(duì)數(shù)據(jù)進(jìn)行加密來(lái)實(shí)現(xiàn)隱私保護(hù)。有兩個(gè)地方比較重要：

（1）加密算法以及對(duì)稱密鑰的安全性，如AES、RC4 和DES 等，本文我們不詳細(xì)展開(kāi)分析對(duì)稱加密的安全性；

（2）密鑰交換的過(guò)程，也就是如何通過(guò)非對(duì)稱加密的方式協(xié)商出一個(gè)對(duì)稱密鑰，如RSA、DHE、ECDHE，本文我們以簡(jiǎn)單的RSA 為例來(lái)介紹非對(duì)稱加密的過(guò)程，幫助大家理解這個(gè)過(guò)程，而不去介紹ECDHE 等基于橢圓曲線的更復(fù)雜的算法。

5.1 非對(duì)稱加密及密鑰交換

在 1976 年以前，所有加密都是對(duì)稱加密方式，這種加密方式最大的問(wèn)題是保存和傳遞密鑰的過(guò)程非常不安全。1976 年兩位計(jì)算機(jī)學(xué)家Whitfield Diffie 和 Martin Hellman，提出了一種嶄新構(gòu)思，可以在不直接傳遞密鑰的情況下，完成解密。這被稱為“Diffie-Hellman密鑰交換算法”。1977 年，三位數(shù)學(xué)家Rivest、Shamir 和 Adleman 設(shè)計(jì)了一種算法，可以實(shí)現(xiàn)非對(duì)稱加密。這種算法用他們?nèi)齻€(gè)人的名字命名，叫做RSA 算法。從那時(shí)直到現(xiàn)在，RSA 算法一直是最廣為使用的”非對(duì)稱加密算法”。毫不夸張地說(shuō)，只要有計(jì)算機(jī)網(wǎng)絡(luò)的地方，就有RSA 算法。這種算法非?？煽?，密鑰越長(zhǎng)越安全。到目前為止被公開(kāi)破解的密鑰長(zhǎng)度
是768 位，可以認(rèn)為1024 位的RSA 密鑰基本安全，2048 位的RSA 密鑰非常安全。

RSA 的安全基于大數(shù)分解的難度。其公鑰和私鑰是一對(duì)大素?cái)?shù)（100 到200 位十進(jìn)制數(shù)或更大）的函數(shù)。從一個(gè)公鑰和密文恢復(fù)出明文的難度，等價(jià)于分解兩個(gè)大素?cái)?shù)之積。

公鑰 Ku：（e，n）

（1） n 是兩個(gè)素?cái)?shù)p 和q 的乘積（其中p 和q 保密）
（2） e 是與（p-1）（q-1）互質(zhì)的數(shù)

私鑰 Kr：（d，n）
（1） n 同上
（2） d 是e?1(mod( p ?1)(q ?1))

加密過(guò)程：C ? Me (mod n)，其中 M 是被加密內(nèi)容，C 是產(chǎn)生的密文；

解密過(guò)程：M ? Cd (mod n)

【Example】下面我們演示一個(gè)例子：

令 p=5，q=11，得出n ? p?q ? 5?11? 55， f (n) ? ( p ?1)?(q ?1) ? 4?10 ? 40。取 e=7

（7 與40 互質(zhì)），下面要計(jì)算得到 d滿足e?d ?1mod f (n)，也就是7?d ?1mod 40。寫

個(gè)程序計(jì)算一下可以取到d=23，于是我們得到了公鑰（7,55）和私鑰（23,55）。

假設(shè)現(xiàn)在的明文是（5,8,16），然后計(jì)算密文如下：

7

7

7

1 ( 1) (mod ) 5 (mod55) 25

2 ( 2) (mod ) 8 (mod55) 2

3 ( 3) (mod ) 16 (mod55) 36

e

e

e

C M n

C M n

C M n

得到密文：25,2,36

最后我們進(jìn)行解密如下：

d 23

d 23

d 23

M1 (C1) (mod ) 25 (mod 55) 5

M2 (C2) (mod ) 2 (mod 55) 8

M3 (C3) (mod ) 36 (mod55) 16

5,8,16

n

n

n

明文：

從上面例子中我們可以看出，明文（5,8,16）通過(guò)公鑰加密得到密文，最后通過(guò)私鑰進(jìn)行解密。當(dāng)然也可以通過(guò)私鑰進(jìn)行加密，然后通過(guò)公鑰進(jìn)行解密，在對(duì)稱密鑰協(xié)商的過(guò)程中就是這樣用的。上面的例子選取的素?cái)?shù)都比較小，實(shí)際運(yùn)用要比這復(fù)雜得多，由于RSA 算法的公鑰私鑰的長(zhǎng)度要到1024 位甚至2048 位才能保證安全，因此，p、q、e 的選取、公鑰私鑰的生成，加密解密模指數(shù)運(yùn)算都有一定的計(jì)算程序，需要仰仗計(jì)算機(jī)完成。

5.2 HTTPS 依然面臨的安全問(wèn)題

雖然HTTPS 通過(guò)SSL 確實(shí)能夠?yàn)楸Ｗo(hù)用戶隱私，防止流量劫持起到很大作用，但是依然存在許多威脅，比如服務(wù)器私鑰的泄露、協(xié)商過(guò)程產(chǎn)生出的對(duì)稱泄露、對(duì)稱加密算法被破解以及中間人攻擊等等。下面我們主要針對(duì)中間人攻擊舉幾個(gè)例子來(lái)說(shuō)明：

【SSLSniff 攻擊】：

圖 10、SSLSniff 攻擊

SSLSniff 屬于中間人攻擊（Man-in-the-MiddleAttack，MITM 攻擊）的一種，過(guò)程如下：

1、攻擊者介于用戶和服務(wù)器之間，偽造證書(shū)，當(dāng)用戶發(fā)送https 請(qǐng)求是攻擊者劫持這個(gè)請(qǐng)求，并返回自己的證書(shū)（非法證書(shū)），同時(shí)它會(huì)繼續(xù)請(qǐng)求服務(wù)器；

2、由于證書(shū)不合法，通常瀏覽器上會(huì)有警示，如果用戶稍加注意能夠避免這種攻擊；

3、攻擊者和服務(wù)器之間是一個(gè)合法的https 連接，服務(wù)器無(wú)法區(qū)分用戶和攻擊者，攻擊者能夠取到服務(wù)器結(jié)果并進(jìn)行篡改，然后以他和用戶之間協(xié)商出來(lái)的密鑰進(jìn)行通信。

【SSLStrip 攻擊】：

圖 11、SSLStrip 攻擊

SSLStrip 攻擊的本質(zhì)是利用一般用戶在瀏覽器地址欄中輸入地址時(shí)一般不會(huì)帶https://的特點(diǎn)，將用戶劫持并對(duì)于后續(xù)服務(wù)器返回結(jié)果中所有帶有https://的地方都替換成http://使得用戶和服務(wù)器之間不會(huì)建立https 連接來(lái)達(dá)到劫持攻擊的目的。過(guò)程如下：

1、一般用戶在瀏覽器地址欄輸入時(shí)不會(huì)選擇https，SSLStrip 利用這個(gè)特點(diǎn)進(jìn)行攻擊

2、正常情況下對(duì)于HTTPS 服務(wù)器，當(dāng)遇到http 請(qǐng)求時(shí)會(huì)做一個(gè)重定向到https

3、攻擊者和用戶之間始終保持http 鏈接，而與服務(wù)器之間保持https 連接。

【降級(jí)攻擊】：

圖12、SSL 降級(jí)攻擊

SSL 3.0 是一個(gè)比較老的協(xié)議，大多數(shù)瀏覽器為了兼容性都會(huì)支持這個(gè)協(xié)議，但是SSL3.0 存在一些安全漏洞。攻擊者就是利用這個(gè)特性，首先讓用戶使用的協(xié)議降級(jí)到SSL 3.0然后利用SSL 3.0 的漏洞進(jìn)行攻擊。

過(guò)程如圖 12 所示：

1、一般情況下用戶發(fā)起請(qǐng)求會(huì)采用更加安全的TLS 1.2/1.1/1.0 協(xié)議，TLS（TransportLayer Security，傳輸層安全協(xié)議）是IETF（Internet Engineering Task Force，Internet 工程任務(wù)組）制定的一種新的協(xié)議，它建立在SSL 3.0 協(xié)議規(guī)范之上，是SSL 3.0 的后續(xù)版本。在TLS 與SSL3.0 之間存在著顯著的差別，主要是它們所支持的加密算法不同，所以TLS 與SSL3.0 不能互操作；

2、中間人（攻擊者）駁回這個(gè)請(qǐng)求，告訴用戶瀏覽器說(shuō)不支持這幾個(gè)協(xié)議，建議其采用SSL 3.0；

3、用戶客戶端降級(jí)采用SSL 3.0，中間人就利用SSL 3.0 進(jìn)行攻擊；

4、攻擊者和服務(wù)器之間依然使用https 建立正常的鏈接，服務(wù)器無(wú)法區(qū)分攻擊者和用戶。

4、參考鏈接

（1） HSTS（RFC 6797）：http://tools./html/rfc6797

（2） TFO 論文：http://conferences./co-next/2011/papers/1569470463.pdf

（3） 完全前向安全Perfect Forward Secrecy：http://de./wiki/Perfect_Forward_Secrecy

（4） SSL: https://www./ssl.htm

（5） SPDY 協(xié)議簡(jiǎn)介及如何編譯含有SPDY 的nginx：http://network.51cto.com/art/201401/426957.htm