關於TLS/SSL協議

因爲http協議是明文傳輸，安全性差，所以要利用https來進行加密傳輸，關鍵點在於TLS/SSL協議

1、TLS/SSL協議的發展

SSL（安全套接層）最初在1994年建立，做爲http的擴展，後來逐步發展爲獨立協議，並更新了三個版本（v1.0、v2.0、v3.0），後來在v3.0基礎上標準化了該協議，並命名爲TLS（傳輸層安全協議v1.0）。所以，TLS能夠理解爲SSL協議的升級版。

2、HTTPS = HTTP + TLS/SSL

因爲TCP協議可保證數據傳輸的可靠性（完整性），所以任何數據到達TCP以前通過TLS/SSL協議處理便可。

• http方案的服務端默認端口爲80
• https方案的服務端默認端口爲443

http通訊風險：

• 冒充風險：冒充他人身份參與通訊
• 竊聽風險：通訊內容被獲取
• 篡改風險：通訊內容被修改

TLS/SSL協議核心：

• 認證
• 密鑰協商
• 數據加密

TLS/SSL協議主要由兩層構成：

• 握手層
• 加密層

3、TLS/SSL握手

開始加密通訊以前，客戶端和服務器首先必須創建鏈接和交換參數，此過程稱爲握手。

相關概念：

1、認證： 客戶端要經過CA機構，採用簽名數字證書的技術方案，對服務端進行身份認證，避免中間人攻擊。

2、密碼套件協商： 客戶端和服務端須要協商出雙方都承認的密碼套件，密碼套件決定了本次鏈接採用的加密算法、密鑰協商算法等各種算法。

3、密鑰協商： 不一樣的密鑰協商算法會有不一樣的握手過程，因爲RSA算法和靜態DH算法都存在前向安全性問題，所以目前使用最多的是DHE算法和ECDHE算法（與服務器密鑰對的關係不大）。

4、握手消息完整性校驗： 握手消息會通過TLS/SSL協議加密層保護，能夠確保握手消息的機密性和完整性，若是握手消息被篡改，則整個握手過程會失敗。

基於RSA算法的握手：

1. 客戶端給出加密協議的版本號、客戶端生成的隨機數和客戶端支持的加密套件。
2. 服務端確認使用加密協議的版本、確認雙方使用的加密套件、提供數字證書（包含公鑰）和隨機數。
3. 客戶端確認數字證書有效性，並返回一個新的使用數字證書中的公鑰加密的隨機數（預主密鑰）
4. 服務端使用本身的私鑰獲取客戶端發來的預主密鑰。

客戶端和服務端根據約定的加密套件，使用前面兩個隨機數和預主密鑰生成主密鑰，以後的通訊使用主密鑰加密解密。

因爲整個握手階段是明文的，所以也存在安全風險（第三個隨機數存在被破解出的風險），能夠將默認的RSA算法改成DH算法提升安全性。

基於DH算法的握手：

1. 客戶端給出加密協議的版本號、客戶端生成的隨機數和客戶端支持的加密套件。
2. 服務端確認使用加密協議的版本、確認雙方使用的加密套件、提供數字證書（包含公鑰）和隨機數。
3. 服務器利用私鑰將客戶端隨機數，服務器隨機數，服務器DH參數簽名，生成服務器簽名。
4. 服務端向客戶端發送服務器DH參數以及服務器簽名。
5. 客戶端向服務端發送客戶端DH參數

以後，客戶端利用公鑰驗證服務器簽名，客戶端與服務器各自利用服務端DH參數、客戶端DH參數生成預主密鑰，再經過預主密鑰、客戶端隨機數、服務端隨機數生成主密鑰(會話密鑰)。最後握手完成，以後的通訊使用主密鑰加密解密。

此外，在認證過程當中，若是客戶端發現服務端證書無效，就會向用戶發出警告，由其選擇是否要繼續通訊。

4、TLS/SSL加密

握手層協商出加密層須要的算法、算法的密鑰塊，加密層則進行加密運算和完整性保護。

目前主要有三種加密模式：

• 流密碼加密模式
• 分組加密模式
• AEAD模式

考慮到加密和完整性運算涉及到的安全性問題，建議採用AEAD加密模式。

5、OpenSSL和TLS/SSL的關係

TLS/SSL協議是設計規範，OpenSSL是目前最通用的TLS/SSL協議實現。

OpenSSL是一個底層密碼庫，封裝了全部的密碼學算法、證書管理、TLS/SSL協議實現。

對於開發者來說，正確地理解並使用底層OpenSSL庫便可。

參考：

• 《深刻淺出HTTPS》
• www.ruanyifeng.com/blog/2014/0…
• www.ruanyifeng.com/blog/2014/0…
• razeen.me/post/ssl-ha…
• segmentfault.com/a/119000000…