https

https:

連接地址：http://op.baidu.com/2015/04/https-s01a01/  http://op.baidu.com/2015/04/https-s01a02/

https ＝ http+tls

目前經常使用的 HTTP 協議是 HTTP1.1，經常使用的 TLS 協議版本有以下幾個：TLS1.2, TLS1.1, TLS1.0 和 SSL3.0。其中 SSL3.0 因爲 POODLE 攻擊已經被證實不安全，但統計發現依然有不到 1% 的瀏覽器使用 SSL3.0。TLS1.0 也存在部分安全漏洞，好比 RC4 和 BEAST 攻擊。

TLS1.2 和 TLS1.1 暫時沒有已知的安全漏洞，比較安全，同時有大量擴展提高速度和性能，推薦你們使用

加密算法通常分爲兩種，對稱加密和非對稱加密。所謂對稱加密（也叫密鑰加密）就是指加密和解密使用的是相同的密鑰。而非對稱加密（也叫公鑰加密）就是指加密和解密使用了不一樣的密鑰。

圖 2 對稱加密

圖 3 非對稱加密

對稱內容加密強度很是高，通常破解不了。但存在一個很大的問題就是沒法安全地生成和保管密鑰。假如客戶端軟件和服務器之間每次會話都使用固定的，相同的密鑰加密和解密，確定存在很大的安全隱患。若是有人從客戶端端獲取到了對稱密鑰，整個內容就不存在安全性了，並且管理海量的客戶端密鑰也是一件很複雜的事情。

非對稱加密主要用於密鑰交換（也叫密鑰協商），可以很好地解決這個問題。瀏覽器和服務器每次新建會話時都使用非對稱密鑰交換算法協商出對稱密鑰，使用這些對稱密鑰完成應用數據的加解密和驗證，整個會話過程當中的密鑰只在內存中生成和保存，並且每一個會話的對稱密鑰都不相同（除非會話複用），中間者沒法竊取。

非對稱密鑰交換很安全，但同時也是 HTTPS 性能和速度嚴重下降的「罪魁禍首」。想要知道 HTTPS 爲何影響速度，爲何消耗資源，就必定要理解非對稱密鑰交換的整個過程。

非對稱加密相比對稱加密更加安全，但也存在兩個明顯缺點：

1，  CPU 計算資源消耗很是大。一次徹底 TLS 握手，密鑰交換時的非對稱解密計算量佔整個握手過程的 90% 以上。而對稱加密的計算量只至關於非對稱加密的 0.1%，若是應用層數據也使用非對稱加解密，性能開銷太大，沒法承受。

2，  非對稱加密算法對加密內容的長度有限制，不能超過公鑰長度。好比如今經常使用的公鑰長度是 2048 位，意味着待加密內容不能超過 256 個字節。

因此公鑰加密目前只能用來做密鑰交換或者內容簽名，不適合用來作應用層傳輸內容的加解密。

非對稱密鑰交換算法是整個 HTTPS 得以安全的基石，充分理解非對稱密鑰交換算法是理解 HTTPS 協議和功能的關鍵。

身份認證：

身份認證主要涉及到 PKI 和數字證書。一般來說 PKI（公鑰基礎設施）包含以下部分：

• End entity：終端實體，能夠是一個終端硬件或者網站。
• CA：證書籤發機構。
• RA：證書註冊及審覈機構。好比審查申請網站或者公司的真實性。
• CRL issuer：負責證書撤銷列表的發佈和維護。
• Repository：負責數字證書及 CRL 內容存儲和分發。

申請一個受信任的數字證書一般有以下流程：

1，  終端實體生成公私鑰和證書請求。

2，  RA 檢查實體的合法性。若是我的或者小網站，這一步不是必須的。

3，  CA 簽發證書，發送給申請者。

4，  證書更新到 repository，終端後續從 repository 更新證書，查詢證書狀態等。

目前百度使用的證書是 X509v3 格式，由以下三個部分組成：

1，  tbsCertificate(to be signed certificate 待簽名證書內容)，這部分包含了 10 個要素，分別是版本號，序列號，簽名算法標識，發行者名稱，有效期，證書主體名，證書主體公鑰信息，發行商惟一標識，主體惟一標識，擴展等。

2，  signatureAlgorithm，簽名算法標識，指定對 tbsCertificate 進行簽名的算法。

3，  signaturValue（簽名值），使用 signatureAlgorithm 對 tbsCertificate 進行計算獲得簽名值。

數字證書有兩個做用：

1，  身份受權。確保瀏覽器訪問的網站是通過 CA 驗證的可信任的網站。

2，  分發公鑰。每一個數字證書都包含了註冊者生成的公鑰。在 SSL 握手時會經過 certificate 消息傳輸給客戶端。好比前文提到的 RSA 證書公鑰加密及 ECDHE 的簽名都是使用的這個公鑰。

申請者拿到 CA 的證書並部署在網站服務器端，那瀏覽器發起握手接收到證書後，如何確認這個證書就是 CA 簽發的呢？怎樣避免第三方僞造這個證書？

答案就是數字簽名（digital signature）。數字簽名是證書的防僞標籤，目前使用最普遍的 SHA-RSA 數字簽名的製做和驗證過程以下：

1，  數字簽名的簽發。首先是使用哈希函數對待簽名內容進行安全哈希，生成消息摘要，而後使用 CA 本身的私鑰對消息摘要進行加密。

2，  數字簽名的校驗。使用 CA 的公鑰解密簽名，而後使用相同的簽名函數對待簽名證書內容進行簽名並和服務端數字簽名裏的簽名內容進行比較，若是相同就認爲校驗成功。

圖 8 數字簽名生成及校驗

這裏有幾點須要說明：

1. 數字簽名簽發和校驗使用的密鑰對是 CA 本身的公私密鑰，跟證書申請者提交的公鑰沒有關係。
2. 數字簽名的簽發過程跟公鑰加密的過程恰好相反，便是用私鑰加密，公鑰解密。
3. 如今大的 CA 都會有證書鏈，證書鏈的好處一是安全，保持根 CA 的私鑰離線使用。第二個好處是方便部署和撤銷，即若是證書出現問題，只須要撤銷相應級別的證書，根證書依然安全。
4. 根 CA 證書都是自簽名，即用本身的公鑰和私鑰完成了簽名的製做和驗證。而證書鏈上的證書籤名都是使用上一級證書的密鑰對完成簽名和驗證的。
5. 怎樣獲取根 CA 和多級 CA 的密鑰對？它們是否可信？固然可信，由於這些廠商跟瀏覽器和操做系統都有合做，它們的公鑰都默認裝到了瀏覽器或者操做系統環境裏。好比firefox 就本身維護了一個可信任的 CA 列表，而chrome 和 IE 使用的是操做系統的 CA 列表。

 

HTTPS 對訪問速度的影響

在介紹速度優化策略以前，先來看下 HTTPS 對速度有什麼影響。影響主要來自兩方面：

1. 協議交互所增長的網絡 RTT(round trip time)。
2. 加解密相關的計算耗時。

HTTPS 首次請求須要的網絡耗時解釋以下：

1，    三次握手創建 TCP 鏈接。耗時一個 RTT。

2，    使用 HTTP 發起 GET 請求，服務端返回 302 跳轉到 https://www.baidu.com。須要一個 RTT 以及 302 跳轉延時。

a)       大部分狀況下用戶不會手動輸入 https://www.baidu.com 來訪問 HTTPS，服務端只能返回 302 強制瀏覽器跳轉到 https。

b)      瀏覽器處理 302 跳轉也須要耗時。

3，    三次握手從新創建 TCP 鏈接。耗時一個 RTT。

a)       302 跳轉到 HTTPS 服務器以後，因爲端口和服務器不一樣，須要從新完成三次握手，創建 TCP 鏈接。

4，    TLS 徹底握手階段一。耗時至少一個 RTT。

a)       這個階段主要是完成加密套件的協商和證書的身份認證。

b)      服務端和瀏覽器會協商出相同的密鑰交換算法、對稱加密算法、內容一致性校驗算法、證書籤名算法、橢圓曲線（非 ECC 算法不須要）等。

c)       瀏覽器獲取到證書後須要校驗證書的有效性，好比是否過時，是否撤銷。

5，    解析 CA 站點的 DNS。耗時一個 RTT。

a)       瀏覽器獲取到證書後，有可能須要發起 OCSP 或者 CRL 請求，查詢證書狀態。

b)      瀏覽器首先獲取證書裏的 CA 域名。

c)       若是沒有命中緩存，瀏覽器須要解析 CA 域名的 DNS。

6，    三次握手創建 CA 站點的 TCP 鏈接。耗時一個 RTT。

a)       DNS 解析到 IP 後，須要完成三次握手創建 TCP 鏈接。

7，    發起 OCSP 請求，獲取響應。耗時一個 RTT。

8，    徹底握手階段二，耗時一個 RTT 及計算時間。

a)       徹底握手階段二主要是密鑰協商。

9，    徹底握手結束後，瀏覽器和服務器之間進行應用層（也就是 HTTP）數據傳輸。

固然不是每一個請求都須要增長 7 個 RTT 才能完成 HTTPS 首次請求交互。大概只有不到 0.01% 的請求才有可能須要經歷上述步驟，它們須要知足以下條件：

1，    必須是首次請求。即創建 TCP 鏈接後發起的第一個請求，該鏈接上的後續請求都不須要再發生上述行爲。

2，    必需要發生徹底握手，而正常狀況下 80% 的請求能實現簡化握手。

3，    瀏覽器須要開啓 OCSP 或者 CRL 功能。Chrome 默認關閉了 ocsp 功能，firefox 和 IE 都默認開啓。

4，    瀏覽器沒有命中 OCSP 緩存。Ocsp 通常的更新週期是 7 天，firefox 的查詢週期也是 7 天，也就說是 7 天中才會發生一次 ocsp 的查詢。

5，    瀏覽器沒有命中 CA 站點的 DNS 緩存。只有沒命中 DNS 緩存的狀況下才會解析 CA 的 DNS。

 

HTTPS 訪問速度優化

2.1 Tcp fast open

HTTPS 和 HTTP 使用 TCP 協議進行傳輸，也就意味着必須經過三次握手創建 TCP 鏈接，但一個 RTT 的時間內只傳輸一個 syn 包是否是太浪費？能不能在 syn 包發出的同時捎上應用層的數據？實際上是能夠的，這也是 tcp fast open 的思路，簡稱 TFO。具體原理能夠參考 rfc7413。

遺憾的是 TFO 須要高版本內核的支持，linux 從 3.7 之後支持 TFO，可是目前的 windows 系統還不支持 TFO，因此只能在公司內部服務器之間發揮做用。

2.2 HSTS

前面提到過將用戶 HTTP 請求 302 跳轉到 HTTPS，這會有兩個影響：

1，    不安全，302 跳轉不只暴露了用戶的訪問站點，也很容易被中間者支持。

2，    下降訪問速度，302 跳轉不只須要一個 RTT，瀏覽器執行跳轉也須要執行時間。

因爲 302 跳轉事實上是由瀏覽器觸發的，服務器沒法徹底控制，這個需求致使了 HSTS 的誕生：

HSTS(HTTP Strict Transport Security)。服務端返回一個 HSTS 的 http header，瀏覽器獲取到 HSTS 頭部以後，在一段時間內，無論用戶輸入www.baidu.com仍是http://www.baidu.com，都會默認將請求內部跳轉成https://www.baidu.com。

Chrome, firefox, ie 都支持了 HSTS（http://caniuse.com/#feat=stricttransportsecurity）。

2.3 Session resume

Session resume 顧名思義就是複用 session，實現簡化握手。複用 session 的好處有兩個：

1，    減小了 CPU 消耗，由於不須要進行非對稱密鑰交換的計算。

2，    提高訪問速度，不須要進行徹底握手階段二，節省了一個 RTT 和計算耗時。

2.4 使用http2