HTTP協議學習---(四)安全篇

時間 2021-06-09 標籤 http

一 HTTPS與SSL/TSL

1 因爲 HTTP 是明文傳輸，所以不安全，容易被黑客竊聽或篡改；

2 通信安全必須同時具備機密性、完整性、身份認證和不可否認這四個特性；
機密性由對稱加密AES保證，完整性由SHA384摘要算法保證，身份認證和不可否認由RSA非對稱加密保證

3 HTTPS 的語法、語義仍然是 HTTP，但把下層的協議由 TCP/IP 換成了 SSL/TLS；

4 SSL/TLS
是信息安全領域中的權威標準，SSL由網景公司發明，在V3之後被互聯網工程組命名爲TSL，最新的是2018年的V1.3，採用多種先進的加密技術保證通信安全；

5 OpenSSL 是著名的開源密碼學工具包，是 SSL/TLS 的具體實現。

6 補充：
TLS 的密碼套件命名非常規範，格式很固定。基本的形式是「**交換算法 + 簽名算法 + 對稱加密算法 + 摘要算法」
例：
圖中表示的是「握手時使用 ECDHE 算法進行**交換，用 RSA 簽名和身份認證，握手後的通信使用 AES 對稱算法，**長度 256 位，分組模式是 GCM，摘要算法 SHA384 用於消息認證和產生隨機數。」

一 TSL 加密方式

1 對稱解密
有一個**，通過這個**可以解密解密數據，目前常用的對稱加密算法有RC4、DES、3DES、AES、ChaCha20。其中RC4、DES、3DES被認爲不安全的，現在基本不再使用。
AES 的意思是「高級加密標準」（Advanced Encryption Standard），**長度可以是 128、192 或 256。它是 DES 算法的替代者，安全強度很高，性能也很好，而且有的硬件還會做特殊優化，所以非常流行，是應用最廣泛的對稱加密算法。(分組加密的概念理解：拿ECB來舉例子，假設使用aes128，**長度是16字節，那麼就把明文按16字節分組，然後每個分組用**加密)。
ChaCha20 是 Google 設計的另一種加密算法，**長度固定爲 256 位，純軟件運行性能要超過 AES，曾經在移動客戶端上比較流行，但 ARMv8 之後也加入了 AES 硬件優化，所以現在不再具有明顯的優勢，但仍然算得上是一個不錯的算法。

2 非對稱加密
對稱加密最大的問題是加密解密都需要一個**來操作，當**被泄露，那麼任何人都可以加密解密其中數據導致不安全。因此出現了非對稱加密，也就是公私鑰對。一般私鑰自己保存，公鑰可以發給任何人。公鑰和私鑰有個特別的「單向」性，雖然都可以用來加密解密，但公鑰加密後只能用私鑰解密，反過來，私鑰加密後也只能用公鑰解密(私鑰加密也可以用公鑰解密的意義在於不能抵賴，因爲私鑰加密只能由持有人發起，所以外部收到的信息如果可以被解密則一定是由持有人發起的)。常用的有DH、DSA、RSA、ECC 等。
RSA 可能是其中最著名的一個，幾乎可以說是非對稱加密的代名詞，它的安全性基於「整數分解」的數學難題，使用兩個超大素數的乘積作爲生成**的材料，想要從公鑰推算出私鑰是非常困難的。
ECC（Elliptic Curve Cryptography）是非對稱加密裏的「後起之秀」，它基於「橢圓曲線離散對數」的數學難題，使用特定的曲線方程和基點生成公鑰和私鑰，子算法 ECDHE 用於**交換，ECDSA 用於數字簽名。
比起 RSA，ECC 在安全強度和性能上都有明顯的優勢。160 位的 ECC 相當於 1024 位的 RSA，而 224 位的 ECC 則相當於 2048 位的 RSA。因爲**短，所以相應的計算量、消耗的內存和帶寬也就少，加密解密的性能就上去了

3 非對稱加密與對稱加密的選擇
非對稱加密效率安全性高但是效率比較低，對稱加密效率高但是安全性比較低。TSL採用混合加密的方式。
先把公鑰給到客戶端，然後客戶端用公鑰加密隨機生成的**作爲之後會話**，服務端用私鑰解密之後拿到會話**，之後通話全都用會話**做對稱加密。

4 信息完整性，摘要算法
即使使用了對稱加密與非對稱加密，這樣只能保證首發雙方以及傳輸過程中的密文安全，但是無法保證中間被多次修改後根據服務器的反應多次修改最終反推出**，因此還要保證信息的完整性。
一般常用的有MD5,SHA-1.但是由於其比較簡單不安全，因此TSL禁用這兩種的算法，而採取了SHA-2。
SHA-2 實際上是一系列摘要算法的統稱，總共有 6 種，常用的有 SHA224、SHA256、SHA384，分別能夠生成 28 字節、32 字節、48 字節的摘要。

5 摘要算法與非對稱加密結合
由於直接對原始的明文進行摘要算法效率低，且容易通過摘要反推出原文，因此可以對上面對稱加密的**進行摘要形成數字簽名，然後用私鑰加密摘要，再用公鑰解密摘要。

6 CA與數字證書
最終要保證雙方是互相信任的就需要有頒發的數字證書，頒發機構就是CA，爲了保證頒發機構是值得信任的就要找頒發機構的上一級頒發機構，最終有一個權威頒發機構，也稱爲自簽名證書或者根證書。雙方順着證書鏈可以找到根證書即表明可信。
作爲信任鏈的源頭 CA 有時也會不可信，解決辦法有 CRL(證書吊銷列表)、OCSP(在線證書狀態協議)，還有終止信任。

7 總結：
①服務器去CA機構申請證書，證書中包含了要發給客戶端的公鑰、簽發者、到期時間等等信息。如果這樣簡單地把證書發給瀏覽器，中間人可以輕鬆地修改成自己的公鑰，之後的通信就是不安全的了。於是需要一定的加密手段，這裏的做法就是使用數字簽名：將證書的信息利用摘要算法計算出摘要之後，用CA的祕鑰進行加密，生成數字簽名。
②服務器將數字證書和數字簽名一起發給瀏覽器，因爲有數字簽名，所以數字證書無法被中間人做修改（修改後的摘要變動了，與簽名裏解密出的原始摘要不匹配，所以能夠發現原文被竄改），瀏覽器拿到數字證書之後，去本地的信任機構中查詢到對應的機構，利用其公鑰解密數字簽名，驗證證書是否有被修改過。這一步就保證了瀏覽器獲取到的公鑰一定是正確的。
③公鑰正確地傳給瀏覽器之後，接着就是協商對稱加密的**，然後通信等等…

二 TSL握手過程

1 TSL 1.2握手過程

①在 TCP 建立連接之後，瀏覽器會首先發一個「Client Hello」消息，也就是跟服務器「打招呼」。裏面有客戶端的版本號、支持的密碼套件，還有一個隨機數（Client Random），用於後續生成會話**。
②服務器收到「Client Hello」後，會返回一個「Server Hello」消息。把版本號對一下，也給出一個隨機數（Server Random），然後從客戶端的列表裏選一個作爲本次通信使用的密碼套件
③服務器爲了證明自己的身份，就把證書也發給了客戶端（Server Certificate）
④因爲服務器選擇了 ECDHE 算法，所以它會在證書後發送「Server Key Exchange」消息，裏面是橢圓曲線的公鑰（Server Params），用來實現**交換算法，再加上自己的私鑰簽名認證。
⑤「Server Hello Done」消息，服務器說：「我的信息就是這些，打招呼完畢。」
這樣第一個消息往返就結束了（兩個 TCP 包），結果是客戶端和服務器通過明文共享了三個信息：Client Random、Server Random 和 Server Params。
⑥此時客戶端開始走證書鏈逐級驗證，確認證書的真實性，再用證書公鑰驗證簽名，就確認了服務器的身份：「剛纔跟我打招呼的不是騙子，可以接着往下走。」
⑦，客戶端按照密碼套件的要求，也生成一個橢圓曲線的公鑰（Client Params），用「Client Key Exchange」消息發給服務器。
⑧現在客戶端和服務器手裏都拿到了**交換算法的兩個參數（Client Params、Server Params），就用 ECDHE 算法一陣算，算出了一個新的東西，叫「Pre-Master」，其實也是一個隨機數。現在客戶端和服務器手裏有了三個隨機數：Client Random、Server Random 和 Pre-Master。用這三個作爲原始材料，就可以生成用於加密會話的主**，叫「Master Secret」。而黑客因爲拿不到「Pre-Master」，所以也就得不到主**。主**有 48 字節，但它也不是最終用於通信的會話**，還會再用 PRF 擴展出更多的**，比如客戶端發送用的會話**（client_write_key）、服務器發送用的會話**（server_write_key）等等
⑨有了主**和派生的會話**，握手就快結束了。客戶端發一個「Change Cipher Spec」，然後再發一個「Finished」消息，把之前所有發送的數據做個摘要，再加密一下，讓服務器做個驗證。
⑩服務器也是同樣的操作，發「Change Cipher Spec」和「Finished」消息，雙方都驗證加密解密 OK，握手正式結束，後面就收發被加密的 HTTP 請求和響應了。

2 TSL1.3握手過程

擴展協議：記錄頭的 Version 字段被兼容性「固定」的情況下，只要是 TLS1.3 協議，握手的「Hello」消息後面就必須有「supported_versions」擴展，它標記了 TLS 的版本號，使用它就能區分新舊協議。
TLS1.3 還有一個安全強化措施，多了個「Certificate Verify」消息，用服務器的私鑰把前面的曲線、套件、參數等握手數據加了簽名，作用和「Finished」消息差不多。但由於是私鑰簽名，所以強化了身份認證和和防竄改。

3 總結
爲了兼容 1.1、1.2 等「老」協議，TLS1.3 會「僞裝」成 TLS1.2，新特性在「擴展」裏實現；
1.1、1.2 在實踐中發現了很多安全隱患，所以 TLS1.3 大幅度刪減了加密算法，只保留了 ECDHE、AES、ChaCha20、SHA-2 等極少數算法，強化了安全；
TLS1.3 也簡化了握手過程，完全握手只需要一個消息往返，提升了性能。

三 HTTPS優化

1 可以有多種硬件和軟件手段減少網絡耗時和計算耗時，讓 HTTPS 變得和 HTTP 一樣快，最可行的是軟件優化；
2 應當儘量使用 ECDHE 橢圓曲線密碼套件，節約帶寬和計算量，還能實現「False Start」；
3 服務器端應當開啓「OCSP Stapling」功能，避免客戶端訪問 CA 去驗證證書；
4 會話複用的效果類似 Cache，前提是客戶端必須之前成功建立連接，後面就可以用「Session ID」「Session Ticket」等憑據跳過**交換、證書驗證等步驟，直接開始加密通信。

四簡答HTTPS爲什麼比HTTP要安全