SSL/TLS
HTTP協議傳輸數據是明文傳輸，任意的人抓包就能看到傳輸的數據，這顯然不安全。1994年，Netscape公司用加密協議增加了HTTP，開始在HTTP的基礎上加入SSL（Secure Socket Layer）。稱為"HTTP over SSL"或者"HTTP Secure"，也就是我們現在熟知的HTTPS。
TLS（Transport Layer Security，傳輸層安全協議）是IETF制定的一種新的協議，TLS1.0是建立在SSL3.0協議規范之上，是SSL3.0協議的后續版本，可以理解為SSL3.1。
TLS加密方式
SSL/TLS分為對稱加密和非對稱加密兩種方式。
對稱加密是指加密和解密都用同一份密鑰（只有一個KEY），常見的有：AES-128，AES-192，AES-256。
非對稱加密對應于一對密鑰，稱為私鑰和公鑰，用私鑰加密后需要用公鑰解密，用公鑰加密后需要用私鑰解密，常見的有：RSA、DSA/DSS。
對稱加密的優點是運算速度快，缺點是互聯網環境下無法將密鑰安全的傳送給對方。非對稱加密的優點是可以安全的將公鑰傳遞給對方，但是運算速度慢。
https先采用非對稱加密傳輸協商對稱加密的密鑰，然后用對稱加密通信。
HTTPS加解密過程
HTTPS的非對稱和對稱加解密過程：
- 客戶端瀏覽器發起連接。
- WEB服務器將公鑰發給客戶端。
- 客戶端生成一個session key，并且將session key用公鑰加密后發送給服務器。
- 服務器用私鑰將session key解密出來。
- 客戶端和服務器用session key做對稱加密通信。
整個流程可以這樣抽象，但是實際上session key的生成是需要多次協商的結果（文章后面會講到），我們暫且這樣簡單的理解。整個流程會有一個問題，第2步中WEB服務器發給客戶端的公鑰，萬一被中間人修改了呢，換句話說，客戶端怎么驗證公鑰的正確性呢？那就需要SSL證書。
HTTPS握手
客戶端通過發送Client Hello消息給服務器初始化Session連接，Client Hello 消息包含以下字段：
SSL/TLS 版本號。version 2 表示的是SSL 2.0，version 3 表示的是SSL 3.0，version 3.1表示的是TLS 1.0。
隨機數Random_C。一共32個字節。前面4個字節是當前時間戳，后面28個字節是一個隨機數。后面協商對稱加密的Session Key會用到。
Session ID。如果是之前已經存在的連接重連，那么Session ID會是一串數字，否則是None。
Cipher Suite。支持的加密組件列表。例如TLS_RSA_WITH_DES_CBC_SHA, TLS 是TLS協議版本，TLS表示TLS1.0，RSA是密鑰交換算法，DES_CBC是加密算法，SHA是摘要算法。
壓縮算法。表示建議選用的是哪種壓縮算法。
Server Hello. 服務器收到客戶端的Client Hello 消息會響應一個Server Hello 消息，包括以下字段：
SSL/TLS 版本，客戶端和服務器都支持的SSL/TLS最高版本。
隨機數Random_S，一共32個字節，前面4個字節是當前時間戳，后面28個字節是一個隨機數。后面協商對稱加密的Session Key會用到。
Session ID，這里會有三種情況。1.產生一個新的Session ID，表示沒有找到之前的Session ID或者之前沒有這個Session ID。2. 返回客戶端帶上的之前的Session ID。（斷鏈重連）3.Null，服務器沒有辦法產生新的Session ID。
Cipher Suite，服務器從剛才Client Hello消息的Cipher Suite加密列表中選中的加密組件。
壓縮算法，表示選中的是哪種壓縮算法。
client Hello 示例:
ClientVersion 3,1 ClientRandom[32] SessionID: None (new session) Suggested Cipher Suites: TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA Suggested Compression Algorithm: NONE
server hello 示例:
Version 3,1 ServerRandom[32] SessionID: bd608869f0c629767ea7e3ebf7a63bdcffb0ef58b1b941e6b0c044acb6820a77 Use Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA Compression Algorithm: NONE
服務器發完Sever Hello 后還會發送下面幾條消息：
Server Certificate.服務器發給客戶端的證書，包含公鑰。客戶端后面會用該密鑰加密premaster secret。客戶端也會校驗證書的合法性，比如證書包含的域名是否就是客戶端正在訪問的域名。
Server Key Exchange.[可選]當服務器的證書不包含公鑰時，客戶端會用它來加密后面的Client Key Exchange消息。
Client Certificate Request.[可選]用于服務器需要驗證客戶端身份的情況，例如銀行系統通常用U盾來證明客戶端的身份。
Server Hello Done.表示Server已經發送消息完畢并且在登陸客戶端回復。
客戶端緊接著響應給服務器的消息：
Client Certificate.[可選]客戶端證書，包括客戶端的公鑰。響應上面的Client Certificate Request。
Client Key Exchange.該消息包括premaster secret,TLS的版本號，再次帶上版本號是因為之前的版本號是明文傳輸的，攻擊者可能會惡意修改為較低的版本號，從而降低連接的安全系數方便發起攻擊。該消息字段會用公鑰加密。現在一共有Random_C,Random_S, premaster secret三個隨機數，客戶端和服務器端會用相同的算法，用這三個隨機數作為參數，從而計算得到另外的一個隨機數，即后面對稱加密的密鑰Session Key。
Certificate Verify.[可選]該消息只針對有Client Certificate的情況。會計算出該消息字段的HASH，然后用客戶端的私鑰加密該HASH作為簽名。服務器端會使用Client Certificate消息中得到的客戶端公鑰解密并驗證這條消息的合法性。
Change Cipher Suite.該消息通知服務器接下來的Client Finish消息將會用剛才協商的密鑰Session Key來加密。
Client Finished.該消息會列舉客戶端上面用到的所有加密字段，并且算出他們的HASH值，然后用Session Key加密。
服務器在握手階段最后回應給客戶端的消息：
Change Cipher Suite Message.該消息通知客戶端接下來的消息會用Session Key來加密。
Sever Finished Message. 對整個協商階段用到的字段算一個HASH，然后用Session Key加密。
SSL證書
在握手過程中，網站會向瀏覽器發送SSL證書，SSL證書和我們日常用的身份證類似，是一個支持HTTPS網站的身份證明，SSL證書里面包含了網站的域名，證書有效期，證書的頒發機構以及用于加密傳輸密碼的公鑰等信息，由于公鑰加密的密碼只能被在申請證書時生成的私鑰解密，因此瀏覽器在生成密碼之前需要先核對當前訪問的域名與證書上綁定的域名是否一致，同時還要對證書的頒發機構進行驗證，如果驗證失敗瀏覽器會給出證書錯誤的提示。
如上圖所示，公鑰內容的后面是會跟上一個數字簽名，該數字簽名是將公鑰內容的HASH用私鑰加密后的密文。客戶端拿到公鑰后，會用相同的HASH算法重新算一遍，得到一個HASH值hash1。然后用公鑰解密數字簽名得到HASH值hash2，如果hash1等于hash2就證明這個公鑰是沒有被中間人修改的。即使中間人修改了公鑰的內容，他也沒有私鑰可以重新生成數字簽名，用戶拿到修改后的公鑰一算發現HASH不對就會報錯。
證書安全
對HTTPS最常見的攻擊手段就是SSL證書欺騙或者叫SSL劫持，是一種典型的中間人攻擊。不過SSL劫持并非只是用于攻擊目的，在一些特殊情況下利用SSL劫持我們可以更順暢的訪問網絡，我會在后文提到。
以攻擊為目的的SSL劫持如果不注意瀏覽器安全提示的話，很容易就中招。當網絡中有中間人發起SSL劫持攻擊時，攻擊者需要偽造一個SSL證書發給瀏覽器，這個時候由于偽造的SSL證書不受信任，瀏覽器會給出提示。
證書驗證
完整性驗證
使用RAS公鑰加密來驗證證書上的簽名是否合法，如果簽名無效，則可認定證書被修改，直接報錯。有效性驗證
CA在頒發證書時，都為每個證書設定了有效期。包括開始時間與結束時間。系統當前時間不在證書起止時間的話，都認為證書是無效的。吊銷狀態驗證
當用戶需要吊銷證書了，那么這里就多了一個證書吊銷狀態的檢測。用戶將需要吊銷的證書通知到CA服務商，CA服務商通知瀏覽器該證書的撤銷狀態。-
發行者驗證
HTTPS數字證書的使用分兩個角色
證書發行方issuer，有簽名密鑰的私鑰
證書申請方subject，使用證書公鑰進行身份驗證的用戶
瀏覽器檢查證書的發行者字段與證書路徑中上級證書的Suject字段相同。
為了增加安全性，大多數PKI實現還驗證發型方的密鑰、簽名跟當前證書的密鑰相同。 但對于信任鏈來說，根證書自己簽發的，也就是說它們的issuer和subject是一樣的。
同時，這些CA根證書都是被操作系統、瀏覽器等直接打入系統的。
image.png 域名規范驗證
中間CA提供了對域名證書的管理以及頒發頒發的顆粒度度控制。證書的生效范圍會限于固定域名、域名范圍（包括子域）或者固定IP。策略約束驗證
法律策略相關檢測。
吊銷狀態驗證
-
Certificate Revocation Lists (CRL)
CA會定期更新發布撤銷證書列表，CRL分布在公共可用的存儲庫中，瀏覽器可以在驗證證書時獲取并查閱CA的最新CRL。
該方法的一個缺陷是撤銷的時間粒度限于CRL發布期。只有在計劃更新所有當前發布的CRL之后，才會通知瀏覽器撤銷。
各家簽名CA廠商的策略不一樣，有的是幾小時，有的是幾天，甚至幾周。
CA證書廠商的CRL數量不一，大部分是30-50個，而GoDaddy有300多個CRL的地址，同時有近30W個證書是吊銷狀態的，文件大小平均達到了1M。
在瀏覽器去校驗證書合法性時，還要去下載一個1M的文件后，再去校驗。校驗通過后才去連想要訪問的網站服務器，這相當浪費時間、效率。
同時，很多瀏覽器所處網絡是有網絡訪問限制的，可能在一個局域網，比如我們村，或者物理距離非常遠，存在嚴重的網絡延遲問題。
image.png Onlie Certificate Status Protocol（OCSP）
為了解決單個文件大，延遲性高等問題，迎來了新的解決方案Onlie Certificate Status Protocol（以下簡稱OCSP）。
在RFC2560X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP的描述中，瀏覽器從在線OCSP服務器（也稱為OCSP Response Server）請求證書的撤銷狀態，OCSP Server予以響應。這種方法避免CRL更新延遲問題。同樣的，X.509 v3證書的OCSP信息也是存儲在拓展信息中。
瀏覽器在獲得Web服務器的公鑰證書后，開始驗證公鑰的合法性，這里會向該公鑰的擴展信息中提供的OCSP Server地址發送OCSP Response，獲得響應后，確認證書有效，再繼續跟Web服務器通信。
OCSP優點：相對于CRL方式，證書吊銷后，CA Server可以立刻將吊銷信息發送給瀏覽器，生效時間快。響應包內容短，不像CRL的響應包，都將近1M以上。
OCSP缺點：
瀏覽器的每次HTTPS請求創建，都需要連接CA OCSP Server進行驗證，有的瀏覽器所在IP與CA OCSP Server的網絡并不是通暢的。而且，OCSP的驗證有網絡IO，花費了很長的時間，嚴重影響了瀏覽器訪問服務器的用戶體驗。
在瀏覽器發送服務器HTTPS證書序號到CA OCSP Server時，也將暴露了用戶的隱私，將用戶訪問的網址透漏給了CA OCSP Server。
- OCSP stapling
OCSP Stapling的方案是解決了CRL、OCSP的缺點，將通過OCSP Server獲取證書吊銷狀況的過程交給Web 服務器來做，Web 服務器不光可以直接查詢OCSP信息，規避網絡訪問限制、OCSP服務器離用戶的物理距離較遠等問題，還可以將查詢響應緩存起來，給其他瀏覽器使用。由于OCSP的響應也是具備CA RSA私鑰簽名的，所以不用擔心偽造問題。
解決了訪問慢的問題
解決了用戶隱私泄露的問題
參考資料
《你不在意的HTTPS證書吊銷機制》(https://zhuanlan.zhihu.com/p/75475419)
《HTTPS與SSL證書概要》（https://zhuanlan.zhihu.com/p/75475419）
