一、HTTPS與HTTP介紹
二、TLS/SSL工作原理
三、TSL/SSL握手過程
四、HTTPS性能優化
五、PKI體系
一、HTTPS與HTTP介紹
1.Https（Secure Hypetext Tranfer Protocol）安全超文本傳輸協議
是一個安全通信通道，基於HTTP開發用於在客戶計算機和服務器之間交換信息，使用安全套接子層（SSL）進行信息交換，換句話說就是使用TLS/SSL加密的HTTP協議，HTTP協議採用明文傳輸信息，存在信息竊聽、信息篡改和信息劫持的風險，而協議SSL具有身份驗證、信息加密和完整性校驗的功能。
HTTPS是在HTTP上建立SSL加密層，並對傳輸數據進行加密，是HTTP協議的安全版。HTTPS主要作用是：
（1）對數據進行加密，並建立一個信息安全通道，來保證傳輸過程中的數據安全；
（2）對網站服務器進行真實身份認證。
2.HTTP（Hypetext Tranfer Protocol）超文本傳輸協議
HTTP是互聯網上應用最為廣泛的一種網絡協議，是一個客戶端和服務器端請求和應答的標準（TCP），用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議。HTTP是採用明文形式進行數據傳輸，極易被不法份子竊取和篡改。
3.HTTPS和HTTP的區別
（1）HTTPS是加密傳輸協議，HTTP是名文傳輸協議；
（2）HTTPS需要用到SSL證書，而HTTP不用；
（3）HTTPS比HTTP更加安全，對搜索引擎更友好
a:為保護用戶隱私安全，谷歌優先索引HTTPS網頁；
b:百度開放收錄https站點，https全網化勢不可擋】；
（4）HTTPS標準端口443，HTTP標準端口80；
（5）HTTPS基於傳輸層，HTTP基於應用層；
（6）HTTPS在瀏覽器顯示綠色安全鎖，HTTP沒有顯示；
HTTP和HTTPS的區別
二、TLS/SSL工作原理
TLS/SSL的功能實現主要依賴於三類基本算法：散列函數Hash、對稱加密和非對稱加密，其利用非對稱加密實現身份認證和密鑰協商，對稱加密算法採用協商的密鑰對數據加密，基於散列函數驗證信息的完整性。
非對稱加密：即常見的RSA算法，還包括ECC、DH等算法，算法特點是，密鑰成對出現，一般稱為公鑰（公開）和私鑰（保密），公鑰加密的信息只能私鑰解開，私鑰加密的信息只能公鑰解開。因此掌握公鑰的不同客戶端之間不能互相解密信息，只能和掌握私鑰的服務器進行加密通信，服務器可以實現1對多的通信，客戶端也可以用來驗證掌握私鑰的服務器身份。特點是信息傳輸1對多，服務器只需要維持一個私鑰就能夠和多個客戶端進行加密通信，但服務器發出的信息能夠被所有的客戶端解密，且該算法的計算複雜，加密速度慢。
對稱加密：常見的有AES-CBC、DES、3DES、AES-GCM等，相同的密鑰可以用於信息的加密和解密，掌握密鑰才能獲取信息，能夠防止信息竊聽，通信方式是1對1；對稱加密的優勢是信息傳輸1對1，需要共享相同的密碼，密碼的安全是保證信息安全的基礎，服務器和N個客戶端通信，需要維持N個密碼記錄，且缺少修改密碼的機制；非對稱加密
散列函數Hash：常見的有MD5、SHA1、SHA256，該類函數特點是函數單向不可逆、對輸入非常敏感、輸出長度固定，針對數據的任何修改都會改變散列函數的結果，用於防止信息篡改並驗證數據的完整性；在信息傳輸過程中，散列函數不能單獨實現信息防篡改，因為明文傳輸，中間人可以修改信息之後重新計算信息摘要，因此需要對傳輸的信息以及信息摘要進行加密；
TLS的基本工作方式是，客戶端使用非對稱加密與服務器進行通信，實現身份驗證並協商對稱加密使用的密鑰，然後對稱加密算法採用協商密鑰對信息以及信息摘要進行加密通信，不同的節點之間採用的對稱密鑰不同，從而可以保證信息只能通信雙方獲取。
三、TSL/SSL握手過程
1.握手與密鑰協商過程
（1）client hello客戶端發起請求，以明文傳輸請求信息，包含版本信息，加密套件候選列表，壓縮算法候選列表，隨機數，擴展字段等信息，相關信息如下：
*支持的最高TSL協議版本version，從低到高依次SSLv2 SSLv3TLSV1TLSV1.1TLSV1.2，當前基本不再使用低於TLSv1的版本；
*客戶端支持的加密套件cipher suites列表，每個加密套件對應前面TLS原理中的四個功能的組合：認證算法Au（身份驗證）、密鑰交換算法KeyExchange（密鑰協商）、對稱加密算法Enc（信息加密）和信息摘要Mac（完整性校驗）；
*支持的壓縮算法compression methods列表，用於後續的信息壓縮傳輸；
*隨機數random_C，用於後續的密鑰的生成；
*擴展字段extensions，支持協議與算法的相關參數以及其它輔助信息等，常見的SNl就屬於擴展字段，後續單獨討論該字段作用。
（2）server hello+server certificate+sever hello done
*server hello，服務端返回協商的信息結果，包括選擇使用的協議版本 version，選擇的加密套件 cipher suite，選擇的壓縮算法compression method、隨機數random_S等，其中隨機數用於後續的密鑰協商；
*server certificates，服務器端配置對應的證書鏈，用於身份驗證與密鑰交換；
*server hello done，通知客戶端 server hello信息發送結束；
（3）證書校驗
客戶端驗證證書的合法性，如果驗證通過才會進行後續通信，否則根據錯誤情況不同做出提示和操作，合法性驗證包括如下：
*I證書鏈]的可信性trusted certificate path，方法如前文所述；
*證書是否吊銷 revocation，有兩類方式離線CRL與在線OCSP，不同的客戶端行為會不同；
*有效期 expiry date，證書是否在有效時間範圍；
*域名domain，核查證書域名是否與當前的訪問域名匹配，匹配規則後續分析；
（4）client key exchange+change_cipher_spec+encrypted handshake_message
（a）client key_exchange，合法性驗證通過之後，客戶端計算產生隨機數字Pre-master，並用證書公鑰加密，發送給服務器；
（b）此時客戶端已經獲取全部的計算協商密鑰需要的信息：兩個明文隨機數random_C和random_S與自己計算產生的Pre-master，計算得到協商密鑰；enc key=Fuc（random_C，random_S，Pre-Master）
（c）change_cipher_spec，客戶端通知服務器後續的通信都採用協商的通信密鑰和加密算法進行加密通信；
（d）encrypted handshake_message，結合之前所有通信參數的hash 值與其它相關信息生成一段數據，採用協商密鑰 session secret 與算法進行加密，然後發送給服務器用於數據與握手驗證；
（5）.change_cipher_spec+encrypted handshake_message
（a）服務器用私鑰解密加密的Pre-master數據，基於之前交換的兩個明文隨機數randomC和randomS，計算得到協商密鑰：enc key=Fuc（random C，random S，Pre-Master）；
（b）計算之前所有接收信息的hash值，然後解密客戶端發送的encrypted_handshake_message，驗證數據和密鑰正確性；
（c）change_cipher_spec，驗證通過之後，服務器同樣發送change_cipher_spec以告知客戶端後續的通信都採用協商的密鑰與算法進行加密通信；
（d）encrypted_handshake_message，服務器也結合所有當前的通信參數信息生成一段數據並採用協商密鑰 session secret 與算法加密併發送到客戶端；
（6）.握手結束
客戶端計算所有接收信息的hash值，並採用協商密鑰解密 encrypted handshake message，驗證服務器發送的數據和密鑰，驗證通過則握手完成；（7）.加密通信
開始使用協商密鑰與算法進行加密通信。
注意：
（a）服務器也可以要求驗證客戶端，即雙向認證，可以在過程2要發送client certificate request信息，客戶端在過程4中先發送client certificate 與certificate verify message 信息，證書的驗證方式基本相同，certificate verify message 是採用client的私鑰加密的一段基於已經協商的通信信息得到數據，服務器可以採用對應的公鑰解密並驗證；
（b）根據使用的密鑰交換算法的不同，如ECC等，協商細節略有不同，總體相似；
（c）sever key exchange的作用是server certificate 沒有攜帶足夠的信息時，發送給客戶端以計算 pre-master，如基於DH的證書，公鑰不被證書中包含，需要單獨發送；
（d）change cipher spec 實際可用於通知對端改版當前使用的加密通信方式，當前沒有深入解析；
（e）alter message 用於指明在握手或通信過程中的狀態改變或錯誤信息，一般告警信息觸發條件是連接關閉，收到不合法的信息，信息解密失敗，用戶取消操作等，收到告警信息之後，通信會被斷開或者由接收方決定是否斷開連接。
2.會話緩存握手過程
為了加快建立握手的速度，減少協議帶來的性能降低和資源消耗，TLS協議有兩類會話緩存機制：會話標識 session ID與會話記錄 session ticket。
session ID由服務器端支持，協議中的標準字段，因此基本所有服務器都支持，服務器端保存會話ID以及協商的通信信息，Nginx中1M內存約可以保存4000個 session ID機器相關信息，佔用服務器資源較多；session ticket 需要服務器和客戶端都支持，屬於一個擴展字段，支持範圍約60%（無可靠統計與來源），將協商的通信信息加密之後發送給客戶端保存，密鑰只有服務器知道，佔用服務器資源很少。
二者對比，主要是保存協商信息的位置與方式不同，類似與http中的session與cookie。
二者都存在的情況下，（nginx實現）優先使用session_ticket。
握手過程如下圖：
注意：雖然握手過程有1.5個來回，但是最後客戶端向服務器發送的第一條應用數據不需要等待服務器返回的信息，因此握手延時是1*RTT。
（1）會話標識 session ID
（a）如果客戶端和服務器之間曾經建立了連接，服務器會在握手成功後返回 session ID，並保存對應的通信參數在服務器中；
（b）如果客戶端再次需要和該服務器建立連接，則在client hello中session ID中攜帶記錄的信息，發送給服務器；
（c）服務器根據收到的 session ID檢索緩存記錄，如果沒有檢索到貨緩存過期，則按照正常的握手過程進行；
（d）如果檢索到對應的緩存記錄，則返回 change_cipher_spec與encrypted handshake_message信息，兩個信息作用類似，encrypted handshake message 是到當前的通信參數與master secret的hash值；
（e）如果客戶端能夠驗證通過服務器加密數據，則客戶端同樣發送change cipher spec與encrypted handshake message 信息；
（g）服務器驗證數據通過，則握手建立成功，開始進行正常的加密數據通信。
（2）會話記錄 session ticket
（a）如果客戶端和服務器之間曾經建立了連接，服務器會在new_session_ticket 數據中攜帶加密的 session_ticket信息，客戶端保存；
（b）如果客戶端再次需要和該服務器建立連接，則在client hello 中擴展字段 session ticket中攜帶加密信息，一起發送給服務器；
（c）服務器解密 sesssion ticket數據，如果能夠解密失敗，則按照正常的握手過程進行；
（d）如果解密成功，則返回change cipher spec與encrypted handshake message 信息，兩個信息作用與session ID中類似；
（f）如果客戶端能夠驗證通過服務器加密數據，則客戶端同樣發送 change cipher spec與encrypted handshake message 信息；
（g）服務器驗證數據通過，則握手建立成功，開始進行正常的加密數據通信。
3.重建連接
重建連接renegotiation即放棄正在使用的TLS連接，從新進行身份認證和密鑰協商的過程，特點是不需要斷開當前的數據傳輸就可以重新身份認證、更新密鑰或算法，因此服務器端存儲和緩存的信息都可以保持。客戶端和服務器都能夠發起重建連接的過程，當前windows 2000&XP與SSL2.0不支持。
（1）服務器重建連接
服務器端重建連接一般情況是客戶端訪問受保護的數據時發生。基本過程如下：
(a) 客戶端和服務器之間建立了有效 TLS 連接並通信;
(b) 客戶端訪問受保護的信息;
(c) 服務器端返回 hello_request 信息;
(d) 客戶端收到 hello_request 信息之後發送 client_hello 信息，開始重新建立連接
（2）客戶端重建連接
客戶端重建連接一般是為了更新通信密鑰。
(a) 客戶端和服務器之間建立了有效 TLS 連接並通信;
(b) 客戶端需要更新密鑰，主動發出 client_hello 信息;
(c) 服務器端收到 client_hello 信息之後無法立即識別出該信息非應用數據，因此會提交給下一步處理，處理完之後會返回通知該信息為要求重建連接;
(d) 在確定重建連接之前，服務器不會立即停止向客戶端發送數據，可能恰好同時或有緩存數據需要發送給客戶端，但是客戶端不會再發送任何信息給服務器;
(e) 服務器識別出重建連接請求之後，發送 server_hello 信息至客戶端;
(f) 客戶端也同樣無法立即判斷出該信息非應用數據，同樣提交給下一步處理，處理之後會返回通知該信息為要求重建連接;
(g) 客戶端和服務器開始新的重建連接的過程。
四、HTTPS性能優化
1.HTTPS性能損耗
(1)增加延時
分析前面的握手過程，一次完整的握手至少需要兩端依次來回兩次通信，至少增加延時2* RTT，利用會話緩存從而複用連接，延時也至少1* RTT*。
(2).消耗較多的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接入的主要難題。
2、HTTPS接入優化
(1).CDN接入
HTTPS 增加的延時主要是傳輸延時 RTT，RTT 的特點是節點越近延時越小，CDN 天然離用戶最近，因此選擇使用 CDN 作為 HTTPS 接入的入口，將能夠極大減少接入延時。CDN 節點通過和業務服務器維持長連接、會話複用和鏈路質量優化等可控方法，極大減少 HTTPS 帶來的延時。
(2).會話緩存
HTTPS 即使採用會話緩存也要至少1*RTT的延時，但是至少延時已經減少為原來的一半，明顯的延時優化;同時，基於會話緩存建立的 HTTPS 連接不需要服務器使用RSA私鑰解密獲取 Pre-master 信息，可以省去CPU 的消耗。如果業務訪問連接集中，緩存命中率高，則HTTPS的接入能力講明顯提升。當前TRP平臺的緩存命中率高峰時期大於30%，10k/s的接入資源實際可以承載13k/的接入，收效非常可觀。
(3).硬件加速
為接入服務器安裝專用的SSL硬件加速卡，作用類似 GPU，釋放 CPU，能夠具有更高的 HTTPS 接入能力且不影響業務程序的。測試某硬件加速卡單卡可以提供35k的解密能力，相當於175核 CPU，至少相當於7臺24核的服務器，考慮到接入服務器其它程序的開銷，一張硬件卡可以實現接近10臺服務器的接入能力。
(4).遠程解密
本地接入消耗過多的 CPU 資源，浪費了網卡和硬盤等資源，考慮將最消耗 CPU 資源的RSA解密計算任務轉移到其它服務器，如此則可以充分發揮服務器的接入能力，充分利用帶寬與網卡資源。遠程解密服務器可以選擇 CPU 負載較低的機器充當，實現機器資源複用，也可以是專門優化的高計算性能的服務器。當前也是 CDN 用於大規模HTTPS接入的解決方案之一。
(5).SPDY/HTTP2
前面的方法分別從減少傳輸延時和單機負載的方法提高 HTTPS 接入性能，但是方法都基於不改變 HTTP 協議的基礎上提出的優化方法，SPDY/HTTP2 利用 TLS/SSL 帶來的優勢，通過修改協議的方法來提升 HTTPS 的性能，提高下載速度等。
五、PKI體系
1.身份驗證的隱患
身份驗證和密鑰協商是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可以進行信息的竊聽、篡改等操作。
另外，服務器也可以對自己的發出的信息進行否認，不承認相關信息是自己發出。因此至少存在兩類問題：中間人攻擊和信息抵賴。
2.身份驗證CA和證書
解決身份驗證和信息抵賴問題的關鍵是確保獲取的公鑰途徑是合法的，能夠驗證服務器的身份信息，為此需要引入權威的第三方機構CA（如沃通CA）。CA負責核實公鑰的擁有者的信息，並頒發認證“證書”，同時能夠為使用者提供證書驗證服務，即PKI體系（PKI基礎知識）。
基本的原理為，CA負責審核信息，然後對關鍵信息利用私鑰進行”簽名”，公開對應的公鑰，客戶端可以利用公鑰驗證簽名。CA也可以吊銷已經簽發的證書，基本的方式包括兩類CRL文件和OCSP。
CA使用具體的流程如下：
（1）服務方S向第三方機構CA提交公鑰、組織信息、個人信息（域名）等信息並申請認證；
（2）CA通過線上、線下等多種手段驗證申請者提供信息的真實性，如組織是否存在、企業是否合法，是否擁有域名的所有權等；
（3）如信息審核通過，CA會向申請者簽發認證文件-證書。
證書包含以下信息：申請者公鑰、申請者的組織信息和個人信息、簽發機構CA的信息、有效時間、證書序列號等信息的明文，同時包含一個簽名；
簽名的產生算法：首先，使用散列函數計算公開的明文信息的信息摘要，然後，採用CA的私鑰對信息摘要進行加密，密文即簽名；
（4）客戶端C向服務器S發出請求時，S返回證書文件；
（5）客戶端C讀取證書中的相關的明文信息，採用相同的散列函數計算得到信息摘要，然後，利用對應CA的公鑰解密簽名數據，對比證書的信息摘要，如果一致，則可以確認證書的合法性，即公鑰合法；
（6）客戶端然後驗證證書相關的域名信息、有效時間等信息；
（7）客戶端會內置信任CA的證書信息（包含公鑰），如果CA不被信任，則找不到對應CA的證書，證書也會被判定非法。
在這個過程注意幾點：
a.申請證書不需要提供私鑰，確保私鑰永遠只能服務器掌握；
b.證書的合法性仍然依賴於非對稱加密算法，證書主要是增加了服務器信息以及簽名；
c.內置CA對應的證書稱為根證書，頒發者和使用者相同，自己為自己簽名，即自簽名證書（為什麼說“部署自籤SSL證書非常不安全"）
d.證書=公鑰+申請者與頒發者信息+簽名；
*即便有人截取服務器A證書，再發給客戶端，想冒充服務器A，也無法實現。因為證書和url的域名是綁定的。
3.證書鏈
如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的被信任。
服務器證書、中間證書與根證書在一起組合成一條合法的證書鏈，證書鏈的驗證是自下而上的信任傳遞的過程。
二級證書結構存在的優勢：
a.減少根證書結構的管理工作量，可以更高效的進行證書的審核與簽發；
b.根證書一般內置在客戶端中，私鑰一般離線存儲，一旦私鑰洩露，則吊銷過程非常困難，無法及時補救；
c.中間證書結構的私鑰洩露，則可以快速在線吊銷，並重新為用戶簽發新的證書；
d.證書鏈四級以內一般不會對HTTPS的性能造成明顯影響。
證書鏈有以下特點：
a.同一本服務器證書可能存在多條合法的證書鏈。
因為證書的生成和驗證基礎是公鑰和私鑰對，如果採用相同的公鑰和私鑰生成不同的中間證書，針對被簽發者而言，該簽發機構都是合法的CA，不同的是中間證書的簽發機構不同；
b.不同證書鏈的層級不一定相同，可能二級、三級或四級證書鏈。
中間證書的簽發機構可能是根證書機構也可能是另一箇中間證書機構，所以證書鏈層級不一定相同。
4、證書吊銷
CA機構能夠簽發證書，同樣也存在機制宣佈以往簽發的證書無效。證書使用者不合法，CA需要廢棄該證書；或者私鑰丟失，使用者申請讓證書無效。主要存在兩類機制：CRL與OCSP。
（1）CRL Certificate Revocation List，證書吊銷列表，一個單獨的文件。該文件包含了CA已經吊銷的證書序列號（唯一）與吊銷日期，同時該文件包含生效日期並通知下次更新該文件的時間，當然該文件必然包含CA私鑰的簽名以驗證文件的合法性。證書中一般會包含一個URL地址CRL Distribution Point，通知使用者去哪裡下載對應的CRL以校驗證書是否吊銷。該吊銷方式的優點是不需要頻繁更新，但是不能及時吊銷證書，因為CRL更新時間一般是幾天，這期間可能已經造成了極大損失。
（2）OCSP Online Certificate Status Protocol，證書狀態在線查詢協議，一個實時查詢證書是否吊銷的方式。請求者發送證書的信息並請求查詢，服務器返回正常、吊銷或未知中的任何一個狀態。證書中一般也會包含一個OCSP的URL地址，要求查詢服務器具有良好的性能。部分CA或大部分的自籤CA（根證書）都是未提供CRL或OCSP地址的，對於吊銷證書會是一件非常麻煩的事情。
此文章特別感謝CSDN博主「hherima」，文章參考供大家學習
原文鏈接：https://blog.csdn.net/hherima/article/details/52469787
閱讀更多 閃電小新 的文章
