關於國密HTTPS 的那些事（二）
關於國密HTTPS 的那些事（二）
三. 需要解決的問題
前文我們了解了https，並梳理了國密https的流程。那麼完成這些流程的目的是什麼呢？又是怎麼來保護數據的安全性呢？我們繼續…
上文我們說到只有http通訊的站點如同在「裸奔」，在客戶端和服務端通訊的時候有巨大的安全隱患。而安全隱患主要有三個方面：明文傳輸，數據篡改，站點劫持。
知道了問題，我們只需要對症下藥：
明文傳輸 ->數據加密傳輸。
數據可篡改->數據完整性校驗。
站點劫持->驗證站點的身份。
還不夠清楚，我們再深入一點，將上面的箭頭繼續往下衍生：
明文傳輸 ->數據加密傳輸- >需要一個只有客戶端和服務端知道的對稱秘鑰（因為對稱秘鑰比非對稱秘鑰效率高）–>秘鑰協商。
數據可篡改->數據完整性校驗->對數據進行哈希計算並簽名–>客戶端和服務端採用同一種數據檢驗的演算法。
站點劫持->驗證站點的身份->客戶端驗證服務端提供的證書是否可信->證書由可信的CA機構頒發（如沃通CA等）。
差不多了，SSL/TLS協議的目的慢慢的就凸顯出來了。知道了SSL/TLS的目的，我們再回過頭看協議，理解起來就相對容易的多。
之前我們也說到了SSL/TLS協議都分為記錄協議和握手協議，而他們目的就是服務客戶端和服務端雙方來來回回的進行數據通訊。
先介紹他們的主要功能，如下：
記錄層協議：將要發送的消息，把數據分塊，壓縮（可選），計算校驗碼HMAC，加密然後傳輸。接收到的數據經過解密、驗證、解壓縮重新封裝然後傳送給高層應用。
握手協議：主要用於客戶端和服務端雙方協商出供記錄層使用的安全參數，進行身份驗證以及向對方報告錯誤等。
接著我們來看SSL/TLS是如何達到自己的目的的，再此之前我們首先需要介紹另一個概念– 加密套件 。
四.關於加密套件
如果將客戶端和服務端比喻成「牛郎」和「織女」，那麼加密套件就如同連接雙方的「鵲橋」。
加密套件為什麼如此重要呢？因為加密套件就定義了他們如何協商對稱秘鑰，採用哪種演算法對數據進行校驗以及簽名，加密套件是雙方建立連接的基礎。
就是因為有了它，「牛郎」和「織女」才能順順利利的在七夕相遇。
我們看加密套件由那幾部分組成，看下圖。
除了協議部分，主要是由：秘鑰交換和認證演算法，加密演算法 和摘要演算法這四部分組成。
加密套件是協議裡面約定的。每個加密套件都有一個ID號。比如0XC02C就是代表了上面的加密套件。
只有客戶端和服務端有同樣的加密套件（有交集），才能通過握手建立https通道。如客戶端支援這個加密套件，服務端也支援這個加密套件，那麼雙方就可以選擇雙方都支援的這個加密套件進行握手。按加密套件中約定的演算法進行數據加密，簽名和交換。
我們在使用抓包工具的時候，就能看到在候客戶端在Client_Hello里就攜帶了自己能支援的加密套件，為什麼發送這麼多呢？因為客戶端也不知道服務端支援哪些加密套件，所以客戶端先把自己支援的加密套件發送給服務端，讓服務端根據自身的協議進行選擇。在實際的應用中，如果客戶端支援的加密套件很多，那麼客戶端會逐步的把所有支援的加密套件都發送給服務端，供服務端選擇。此時客戶端的獨白是：「我已經儘力了，成不成就看緣分了」。服務端接收到客戶端的加密套件後，如果正好有自己支援的加密套件–恭喜，配對成功（當然服務端也是有選擇權的可以配置選擇的優先順序，當有遇到多個支援的加密套件時候優先選擇一些安全性更高的加密套件）。如果客戶端發送的加密套件服務端都不支援，那隻能回復客戶端，期待下一次的緣分了。所以，作為服務端，在保證安全的情況下，盡量支援多的套件和協議，這樣才有更好的兼容性。
現在我們看到抓包工具中的一長串的加密套件，就不奇怪了。原來他們都是期待在茫茫人海中，被「選中」的一個，見下圖。
好了，今天就聊這麼多。下文我們接著揭露協議中握手雙方的來來回回的背後，到底還隱藏了哪些不為人知的秘密！
