深入瞭解解析Https - 從瞭解到放棄

摘要： Https的概念 文末有驚喜， 以下相關名詞均摘自wikipedia Https超文字傳輸安全協議（英語：Hypertext Transfer Protocol Secure，縮寫：HTTPS，常稱為HTTP over TLS，HTTP over SSL或HTTP Secure）...

Https的概念

文末有驚喜， 以下相關名詞均摘自wikipedia

Https超文字傳輸安全協議（英語：Hypertext Transfer Protocol Secure，縮寫：HTTPS，常稱為HTTP over TLS，HTTP over SSL或HTTP Secure）是一種通過計算機網路進行安全通訊的傳輸協議。HTTPS經由HTTP進行通訊，但利用SSL/TLS來加密資料包。HTTPS開發的主要目的，是提供對網站伺服器的身份認證，保護交換資料的隱私與完整性。這個協議由網景公司（Netscape）在1994年首次提出，隨後擴充套件到網際網路上。

SSL安全套接層（Secure Sockets Layer）是netscape設計的主要用於Web的安全傳輸協議,位於可靠的面向連線的網路層協議和應用層協議之間的一種協議層。

TLS傳輸層安全協議（英語：Transport Layer Security） 用於兩個應用程式之間提供保密性和資料完整性。

IETF網際網路工程任務小組（英語：Internet Engineering Task Force，縮寫為IETF）負責網際網路標準的開發和推動。

TLS與SSL關係

TLS的前身是 SSL3.0 協議，最早由netscape公司於 1995 年釋出，1999 年經過 IETF 討論和規範後，改名為 TLS。如果沒有特別說明，SSL 和 TLS 說的都是同一個協議。

目前有以下幾個版本：SSLv2，SSLv3，TLSv1，TLSv1.1，TLSv1.2，TLSv1.3(草案)當前基本不再使用低於 TLSv1 的版本

Https與Http

TLS/SSL協議的基本概念

TLS/SSL的功能實現主要依賴於三類基本演算法：雜湊函式 Hash、對稱加密和非對稱加密，其利用非對稱加密實現身份認證和金鑰協商，對稱加密演算法採用協商的金鑰對資料加密，基於雜湊函式驗證資訊的完整性

• 雜湊函式Hash：常見的有 MD5、SHA1、SHA256，該類函式特點是函式單向不可逆、對輸入非常敏感、輸出長度固定，針對資料的任何修改都會改變雜湊函式的結果，用於防止資訊篡改並驗證資料的完整性；

• 對稱加密：常見的有 AES-CBC、DES、3DES、AES-GCM等，相同的金鑰可以用於資訊的加密和解密，掌握金鑰才能獲取資訊，能夠防止資訊竊聽，通訊方式是1對1；

• 非對稱加密：即常見的 RSA、ECDHE、DH 、DHE等演算法，演算法特點是，金鑰成對出現，一般稱為公鑰(公開)和私鑰(保密)，公鑰加密的資訊只能私鑰解開，私鑰加密的資訊只能公鑰解開。因此掌握公鑰的不同客戶端之間不能互相解密資訊，只能和掌握私鑰的伺服器進行加密通訊，伺服器可以實現1對多的通訊，客戶端也可以用來驗證掌握私鑰的伺服器身份。

對稱加密的弊端

1. 要求提供一條安全的通道使通訊雙方在首次通訊時協商一個共同的金鑰。直接面對面協商可能難於實施，所以雙方需要藉助於郵件和電話等其他相對不夠安全的手段來進行協商。

2. 金鑰的數目難於管理。因為對於每一個合作者都需要使用不同的金鑰，很難適應開放社 會中大量的資訊交流。

   對稱加密演算法一般不能提供資訊完整性的鑑別。它無法驗證傳送者和接受者的身份。

3. 對稱金鑰的管理和分發工作是一件具有潛在危險的、繁瑣的過程。對稱加密是基於共同保守祕密來實現的，採用對稱加密技術的貿易雙方必須保證採用的是相同的金鑰，保證彼此金鑰的交換是安全可靠的，同時還要設定防止密匍洩密和更改金鑰的程式。

非對稱加密的弊端

先天不足

在公開金鑰密碼體制中，常用的一種是RSA加密演算法。其數學原理是將一個大數分解成兩個質數的乘積，加密和解密用的是兩個不同的金鑰。即使己知明文、密文和加密金鑰(公鑰)，想要推匯出解密金鑰(私鑰)，在計算上是不可能的。按現在的計算機技術水平，要破解目前採用的1024位RSA金鑰，需要上千年的計算時間。公開金鑰技術解決了金鑰釋出的管理問題，商家可以公開其公開金鑰，而保留其私有金鑰。在2010年以後，均採用了2048位的簽名

身份驗證和金鑰協商是TLS的基礎功能，要求的前提是合法的伺服器掌握著對應的私鑰。但RSA演算法無法確保伺服器身份的合法性，因為公鑰並不包含伺服器的資訊

中間人攻擊和資訊抵賴

1. 客戶端C和伺服器S進行通訊，中間節點M截獲了二者的通訊；

2. 節點M自己計算產生一對公鑰pub_M和私鑰pri_M；

3. C向S請求公鑰時，M把自己的公鑰pub_M發給了C；

4. C使用公鑰 pub_M加密的資料能夠被M解密，因為M掌握對應的私鑰pri_M，而 C無法根據公鑰資訊判斷伺服器的身份，從而 C和 M之間建立了"可信"加密連線；

5. 中間節點 M和伺服器S之間再建立合法的連線，因此 C和 S之間通訊被M完全掌握，M可以進行資訊的竊聽、篡改等操作。

6. 伺服器也可以對自己的發出的資訊進行否認，不承認相關資訊是自己發出。

橫空出世的CA驗證及證書

CA （Certification Authority）負責稽核資訊，然後對關鍵資訊利用私鑰進行"簽名"，公開對應的公鑰，客戶端可以利用公鑰驗證簽名。CA也可以吊銷已經簽發的證書，具體的流程如下：

相關

1. 申請證書不需要提供私鑰，確保私鑰永遠只能伺服器掌握；
2. 證書的合法性仍然依賴於非對稱加密演算法，證書主要是增加了伺服器資訊以及簽名；
3. 內建 CA 對應的證書稱為根證書，頒發者和使用者相同，自己為自己簽名，即自簽名證書；
4. 證書=公鑰+申請者與頒發者資訊+簽名；
5. 公鑰放在數字證書中。只要證書是可信的，公鑰就是可信的。

如何驗證證書的合法性

客戶端針對服務端用私鑰對證書資訊簽名的校驗

當客戶端對服務端傳送client_hello之後 服務端會將公開的金鑰證書傳送給客戶端,證書中包含了 公鑰 , 各種資訊 , 簽名 (ca針對證書的摘要資訊進行私鑰加密)

當客戶端接收到證書後會通過內建ca公鑰對簽名進行解密已驗證證書的合法性.如果已知的ca公鑰均無法解密證書籤名,則認定當前證書不是被認可的證書(沒有頒佈本證書或者證書被偽造)

證書鏈

證書鏈:伺服器證書、中間證書與根證書在一起組合成一條合法的證書鏈，證書鏈的驗證是自下而上的信任傳遞的過程。

如 CA根證書和伺服器證書中間增加一級證書機構，即中間證書，證書的產生和驗證原理不變，只是增加一層驗證，只要最後能夠被任何信任的CA根證書驗證合法即可。

1. 伺服器證書 server.pem 的簽發者為中間證書機構 inter，inter 根據證書 inter.pem 驗證 server.pem 確實為自己簽發的有效證書；
2. 中間證書 inter.pem 的簽發 CA 為 root，root 根據證書 root.pem 驗證 inter.pem 為自己簽發的合法證書；
3. 客戶端內建信任 CA 的 root.pem 證書，因此伺服器證書 server.pem 的被信任。

證書鏈的優勢與特點

• 減少根證書結構的管理工作量，可以更高效的進行證書的稽核與簽發；
• 根證書一般內建在客戶端中，私鑰一般離線儲存，一旦私鑰洩露，則吊銷過程非常困難，無法及時補救；
• 中間證書結構的私鑰洩露，則可以快速線上吊銷，並重新為使用者簽發新的證書；
• 證書鏈四級以內一般不會對 HTTPS 的效能造成明顯影響。
• 同一本伺服器證書可能存在多條合法的證書鏈。因為證書的生成和驗證基礎是公鑰和私鑰對，如果採用相同的公鑰和私鑰生成不同的中間證書，針對被簽發者而言，該簽發機構都是合法的 CA，不同的是中間證書的簽發機構不同；
• 不同證書鏈的層級不一定相同，可能二級、三級或四級證書鏈。中間證書的簽發機構可能是根證書機構也可能是另一箇中間證書機構，所以證書鏈層級不一定相同。

證書吊銷

CA 機構能夠簽發證書，同樣也存在機制宣佈以往簽發的證書無效。證書使用者不合法，CA 需要廢棄該證書；或者私鑰丟失，使用者申請讓證書無效。主要存在兩類機制：CRL與OCSP。

CRL

Certificate Revocation List， 證書吊銷列表，是一個單獨的檔案。該檔案包含了 CA 已經吊銷的證書序列號(唯一)與吊銷日期，同時該檔案包含生效日期並通知下次更新該檔案的時間，當然該檔案必然包含 CA 私鑰的簽名以驗證檔案的合法性。

在證書中一般會包含一個 URL 地址 CRL Distribution Point，通知使用者去哪裡下載對應的 CRL 以校驗證書是否吊銷。該吊銷方式的優點是不需要頻繁更新，但是不能及時吊銷證書，因為 CRL 更新時間一般是幾天，這期間可能已經造成了極大損失。

OCSP

Online Certificate Status Protocol， 證書狀態線上查詢協議，一個實時查詢證書是否吊銷的方式。請求者傳送證書的資訊並請求查詢，伺服器返回正常、吊銷或未知中的任何一個狀態。

證書中一般也會包含一個 OCSP 的 URL 地址，要求查詢伺服器具有良好的效能。部分 CA 或大部分的自籤 CA (根證書)都是未提供 CRL 或 OCSP 地址的，對於吊銷證書會是一件非常麻煩的事情。

TLS/SSL握手過程

X.509

X.509 是一個標準，也是一個數字文件，這個文件根據RFC 5280來編碼並簽發，一份X.509證書是一些標準欄位的集合，這些欄位包含有關使用者或裝置及其相應公鑰的資訊。

編碼 (也用於副檔名)

• .DER - 副檔名DER用於二進位制DER編碼的證書，不可讀。這些證書也可以用CER或者CRT作為副檔名。 Java和Windows伺服器偏向於使用這種編碼格式，比較合適的說法是“我有一個DER編碼的證書”，而不是“我有一個DER證書”。

• .PEM - 副檔名PEM用於ASCII(Base64)編碼的各種X.509 v3 證書。以“-----BEGIN...”開頭， “-----END...”結尾，內容是BASE64編碼，Apache和Linux伺服器偏向於使用這種編碼格式。

常用的副檔名

• .KEY - 通常用來存放一個公鑰或者私鑰，並非X.509證書，編碼可能是PEM，也可能是DER.

• .CSR - 是Certificate Signing Request的縮寫，即證書籤名請求，這不是證書，是生成證書時要把這個提交給權威的證書頒發機構。其核心內容是一個公鑰(當然還附帶了一些別的資訊)，在生成這個申請的時候，同時也會生成一個私鑰，私鑰要自己保管好.當權威證書頒發機構頒發的證書過期的時候，你還可以用同樣的csr來申請新的證書，key保持不變.

• .CRT - certificate的縮寫，其實還是證書的意思，常見於Linux系統，有可能是PEM或者DER編碼，大多數應該是PEM編碼.

• .CER - certificate的縮寫，其實還是證書的意思，常見於Windows系統，有可能是PEM或者DER編碼，大多數應該是DER編碼.

注意：CRT檔案和CER檔案只有在使用相同編碼的時候才可以安全地相互替代。

• .PFX/PKCS12 - predecessor of PKCS#12，包含了證書和私鑰，對Linux伺服器來說，一般來說CRT和KEY是分開存放在不同檔案中的，但Windows的IIS則將它們存在一個PFX檔案中，並通過提取密碼來保護。

• .JKS/JCEKS - Java金鑰庫(KeyStore)的兩種比較常見型別，包含了證書和私鑰，利用Java的“keytool”的工具，可以將PFX轉為JKS，當然了，keytool也能直接生成JKS，JCEKS在安全級別上要比JKS強，使用的Provider是JCEKS(推薦)，使用使用TripleDES 保護KeyStore中的私鑰；

• .BKS – Bouncy Castle Provider，包含了證書和私鑰， android系統支援的型別，它使用的也是TripleDES來保護金鑰庫中的私鑰，它能夠防止證書庫被不小心修改（Keystore的keyentry改掉1個bit都會產生錯誤），BKS能夠跟JKS互操作。

注意：通過工具 BKS、JKS、PFX 三種格式的證書均可以相互轉換

OpenSSL

OpenSSL簡單地說，OpenSSL是SSL的一個實現，SSL只是一種規範理論上來說，SSL這種規範是安全的，目前的技術水平很難破解，但SSL的實現就可能有些漏洞，如著名的“心臟出血”。OpenSSL還提供了一大堆強大的工具軟體，強大到90%我們都用不到.

證書編碼的轉換

PEM轉為DER openssl x509 -in cert.crt -outform der -out cert.der

DER轉為PEM openssl x509 -in cert.crt -inform der -outform pem -out cert.pem

(提示:要轉換KEY檔案也類似，只不過把x509換成rsa，要轉CSR的話，把x509換成req...)

"心臟出血"事件

2014年曝光了OpenSSL的原始碼中存在一個漏洞，可以讓攻擊者獲得伺服器上64K記憶體中的資料內容

OpenSSL心臟出血漏洞的大概原理是OpenSSL在2012年引入了心跳(heartbeat)機制來維持TLS連結的長期存在，心跳機制是作為TLS的擴充套件實現，但在程式碼中包括TLS(TCP)和DTLS(UDP)都沒有做邊界的檢測，所以導致攻擊者可以利用這個漏洞來獲得TLS連結對端（可以是伺服器，也可以是客戶端）記憶體中的一些資料，至少可以獲得16KB每次，理論上講最大可以獲取64KB。

Alexa排名前百萬的網站中有40.9%的網站收到影響

Https主要流程

client	server
1 Client Hello
	2 Server Hello
	3 certificate
	4 server_key_exchange(DH加密需要)
	5 certificate_request(雙向驗證需要)
	6 server_hello_done
7 certificate(雙向驗證需要)
8 client_key_exchange
9 certifiate_verify(雙向驗證需要)
10 change_cypher_spec
11 encrypted handshake message
----finished----
	12 change_cypher_spec
	13 encrypted handshake message
	----finished----

Wireshark抓包例項

1. Client Hello (C-S)

   

   Client Hello (C-S)

1.提供最高支援的TLS/SSl版本

2.客戶端生成隨機數random_c

3.客戶端支援的加密方式

2. Server Hello(S-C)

   

   Server Hello(S-C)

   1.協商後使用的TLS/SSl版本

   2.服務端生成隨機數random_s

   3.協商後使用的加密方式

   (上圖中使用的是RSA和DH混合使用的方式,RSA驗證伺服器身份,DH演算法加密金鑰)

3. Certificate (S-C)/可選

   

   Certificate (S-C)/可選

提供伺服器的身份證書給客戶端鑑定，如果不用公鑰證書體系驗證身份和交換金鑰，該步驟可選，比如在用DH方法交換的時候。

4. Server Key Exchange (S-C)/可選

   

   Server Key Exchange/Server Hello Done

金鑰交換用到的伺服器方的資訊，一般是補充上次的 [Certificate]指令的資訊，如果才用DH加密算演算法需要提供.

5. certificate_request(S-C)/可選

   服務端要求客戶端提供證書,包括客戶端可以提供的證書型別及伺服器接受的證書distinguished name列表，可以是root CA或者subordinate CA

6. Server Hello Done (S-C)

   

   Server Key Exchange/Server Hello Done

   結束伺服器端的握手過程

7. certificate(C-S)/可選

   如果服務端需要客戶端提供證書,則在此提供客戶端的證書

8. Client Key Exchange (C-S)

   

   Client Key Exchange

   客戶端會在生成一個隨機數pubkey並將它傳送到服務端,客戶端與服務端均會根據之前生成的random_c,random_s,pubkey三個隨機數生成對稱加密的session secret

9. certifiate_verify(C-S)/可選

   傳送使用客戶端證書給到這一步為止收到和傳送的所有握手訊息簽名結果

10. Change Cipher Spec (C-S)

通知服務端接下來的資料均採用session secret為key對稱加密方式

11. Encrypted Handshake Message(C-S)

客戶端隨後立刻傳送了一個經過加密的訊息, 服務端應該可以根據生成的session secret來進行解密,這個加密的訊息解密以後是有固定格式的，符合這個格式，或則滿足一些字元匹配，才是合法的。

12. Change Cipher Spec(S-C)

通知客戶端接下來的資料均採用被session secret加密的對稱加密方式

13. Encrypted Handshake Message(S-C)

服務端隨後也立刻傳送了一個經過加密的訊息,讓給客戶端進行驗證

14. 正式的資料互動

    隨後兩端都會通過已經協商好的session secret作為key的對稱加密方式通過http協議進行資料互動

自簽名證書的不安全性

1. 自簽證書最容易被假冒和偽造，而被欺詐網站所利用

• 自簽證書最容易受到SSL中間人攻擊
• 以上這兩點都是由於自簽證書不受瀏覽器信任，而網站告訴使用者要信任而造成
• 自簽證書支援不安全的SSL通訊重新協商機制(Dos及中間人攻擊)
• 自簽證書支援非常不安全的SSL V2.0協議
• 自簽證書沒有可訪問的吊銷列表
• 自簽證書使用1024位的非對稱金鑰對
• 自簽證書證書有效期太長，短則5年，長則20年、30年

HTTPS效能損耗

增加延時

分析前面的握手過程，一次完整的握手至少需要兩端依次來回兩次通訊，至少增加延時2 RTT（Round-Trip Time，往返時間），利用會話快取從而複用連線，延時也至少1 RTT。

消耗較多的CPU資源

除資料傳輸之外，HTTPS通訊主要包括對對稱加解密、非對稱加解密(伺服器主要採用私鑰解密資料)；壓測 TS8 機型的單核 CPU：對稱加密演算法AES-CBC-256 吞吐量 600Mbps，非對稱 RSA 私鑰解密200次/s。不考慮其它軟體層面的開銷，10G 網絡卡為對稱加密需要消耗 CPU 約17核，24核CPU最多接入 HTTPS 連線 4800；

靜態節點當前10G 網絡卡的 TS8 機型的 HTTP 單機接入能力約為10w/s，如果將所有的HTTP連線變為HTTPS連線，則明顯RSA的解密最先成為瓶頸。因此，RSA的解密能力是當前困擾HTTPS接入的主要難題。

HTTPS接入優化

CDN接入

HTTPS 增加的延時主要是傳輸延時 RTT，RTT 的特點是節點越近延時越小，CDN 天然離使用者最近，因此選擇使用 CDN 作為 HTTPS 接入的入口，將能夠極大減少接入延時。CDN 節點通過和業務伺服器維持長連線、會話複用和鏈路質量優化等可控方法，極大減少 HTTPS 帶來的延時。

會話快取

雖然前文提到 HTTPS 即使採用會話快取也要至少1*RTT的延時，但是至少延時已經減少為原來的一半，明顯的延時優化；同時，基於會話快取建立的 HTTPS 連線不需要伺服器使用RSA私鑰解密獲取 Pre-master 資訊，可以省去CPU 的消耗。如果業務訪問連線集中，快取命中率高，則HTTPS的接入能力講明顯提升。當前TRP平臺的快取命中率高峰時期大於30%，10k/s的接入資源實際可以承載13k/的接入，收效非常可觀。

硬體加速

為接入伺服器安裝專用的SSL硬體加速卡，作用類似 GPU，釋放 CPU，能夠具有更高的 HTTPS 接入能力且不影響業務程式的。測試某硬體加速卡單卡可以提供35k的解密能力，相當於175核 CPU，至少相當於7臺24核的伺服器，考慮到接入伺服器其它程式的開銷，一張硬體卡可以實現接近10臺伺服器的接入能力。

遠端解密

本地接入消耗過多的 CPU 資源，浪費了網絡卡和硬碟等資源，考慮將最消耗 CPU 資源的RSA解密計算任務轉移到其它伺服器，如此則可以充分發揮伺服器的接入能力，充分利用頻寬與網絡卡資源。遠端解密伺服器可以選擇 CPU 負載較低的機器充當，實現機器資源複用，也可以是專門優化的高計算效能的伺服器。當前也是 CDN 用於大規模HTTPS接入的解決方案之一。

SPDY/HTTP2

前面的方法分別從減少傳輸延時和單機負載的方法提高 HTTPS 接入效能，但是方法都基於不改變 HTTP 協議的基礎上提出的優化方法，SPDY/HTTP2 利用 TLS/SSL 帶來的優勢，通過修改協議的方法來提升 HTTPS 的效能，提高下載速度等。

【附錄】

需要資料的朋友可以加入Android架構交流QQ群聊：513088520

點選連結加入群聊【Android移動架構總群】： 加入群聊

獲取免費學習視訊，學習大綱另外還有像高階UI、效能優化、架構師課程、NDK、混合式開發（ReactNative+Weex）等Android高階開發資料免費分享。