深刻了解解析Https - 從瞭解到放棄

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：常見的有 MD五、SHA一、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)

   

1.提供最高支持的TLS/SSl版本 2.客戶端生成隨機數random_c 3.客戶端支持的加密方式

2. Server Hello(S-C)

   

   1.協商後使用的TLS/SSl版本 2.服務端生成隨機數random_s 3.協商後使用的加密方式

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

3. Certificate (S-C)/可選

   

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

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

   

密鑰交換用到的服務器方的信息，通常是補充上次的 [Certificate]指令的信息，若是才用DH加密算算法須要提供.

5. certificate_request(S-C)/可選 服務端要求客戶端提供證書,包括客戶端能夠提供的證書類型及服務器接受的證書distinguished name列表，能夠是root CA或者subordinate CA

6. Server Hello Done (S-C)

   

   結束服務器端的握手過程

7. certificate(C-S)/可選 若是服務端須要客戶端提供證書,則在此提供客戶端的證書

8. Client Key Exchange (C-S)

   

   客戶端會在生成一個隨機數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性能損耗

增長延時

分析前面的握手過程，一次完整的握手至少須要兩端依次來回兩次通訊，至少增長延時2RTT（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程序員面試簡歷模板，面試涉及到的絕大部分面試題及答案作成了文檔和架構視頻資料免費分享給你們【包括高級UI、性能優化、架構師課程、NDK、Kotlin、混合式開發（ReactNative+Weex）、Flutter等架構技術資料】，但願能幫助到您面試前的複習且找到一個好的工做，也節省你們在網上搜索資料的時間來學習。

資料獲取方式：加入Android架構交流QQ羣聊：513088520 ，進羣即領取資料！！！

點擊連接加入羣聊【Android移動架構總羣】：加入羣聊