由於http協議是明文傳輸，安全性差，因此要利用https來進行加密傳輸，關鍵點在於TLS/SSL協議
一、TLS/SSL協議的發展
SSL（安全套接層）最初在1994年建立，作為http的擴充套件，後來逐步發展為獨立協議，並更新了三個版本（v1.0、v2.0、v3.0），後來在v3.0基礎上標準化了該協議，並命名為TLS（傳輸層安全協議v1.0）。因此，TLS可以理解為SSL協議的升級版。
二、HTTPS = HTTP + TLS/SSL
由於TCP協議可保證資料傳輸的可靠性（完整性），因此任何資料到達TCP之前經過TLS/SSL協議處理即可。
- http方案的服務端預設埠為80
- https方案的服務端預設埠為443
http通訊風險：
- 冒充風險：冒充他人身份參與通訊
- 竊聽風險：通訊內容被獲取
- 篡改風險：通訊內容被修改
TLS/SSL協議核心：
- 認證
- 金鑰協商
- 資料加密
TLS/SSL協議主要由兩層構成：
- 握手層
- 加密層
三、TLS/SSL握手
開始加密通訊之前，客戶端和伺服器首先必須建立連線和交換引數，此過程稱為握手。
相關概念：
一、認證： 客戶端要通過CA機構，採用簽名數字證書的技術方案，對服務端進行身份認證，避免中間人攻擊。
二、密碼套件協商： 客戶端和服務端需要協商出雙方都認可的密碼套件，密碼套件決定了本次連線採用的加密演算法、金鑰協商演算法等各類演算法。
三、金鑰協商： 不同的金鑰協商演算法會有不同的握手過程，由於RSA演算法和靜態DH演算法都存在前向安全性問題，因此目前使用最多的是DHE演算法和ECDHE演算法（與伺服器金鑰對的關係不大）。
四、握手訊息完整性校驗： 握手訊息會經過TLS/SSL協議加密層保護，可以確保握手訊息的機密性和完整性，如果握手訊息被篡改，則整個握手過程會失敗。
基於RSA演算法的握手：
- 客戶端給出加密協議的版本號、客戶端生成的隨機數和客戶端支援的加密套件。
- 服務端確認使用加密協議的版本、確認雙方使用的加密套件、提供數字證書（包含公鑰）和隨機數。
- 客戶端確認數字證書有效性，並返回一個新的使用數字證書中的公鑰加密的隨機數（預主金鑰）
- 服務端使用自己的私鑰獲取客戶端發來的預主金鑰。
客戶端和服務端根據約定的加密套件，使用前面兩個隨機數和預主金鑰生成主金鑰，之後的通訊使用主金鑰加密解密。
由於整個握手階段是明文的，因此也存在安全風險（第三個隨機數存在被破解出的風險），可以將預設的RSA演算法改為DH演算法提高安全性。
基於DH演算法的握手：
- 客戶端給出加密協議的版本號、客戶端生成的隨機數和客戶端支援的加密套件。
- 服務端確認使用加密協議的版本、確認雙方使用的加密套件、提供數字證書（包含公鑰）和隨機數。
- 伺服器利用私鑰將客戶端隨機數，伺服器隨機數，伺服器DH引數簽名，生成伺服器簽名。
- 服務端向客戶端傳送伺服器DH引數以及伺服器簽名。
- 客戶端向服務端傳送客戶端DH引數
之後，客戶端利用公鑰驗證伺服器簽名，客戶端與伺服器各自利用服務端DH引數、客戶端DH引數生成預主金鑰，再通過預主金鑰、客戶端隨機數、服務端隨機數生成主金鑰(會話金鑰)。最後握手完成，之後的通訊使用主金鑰加密解密。
此外，在認證過程中，如果客戶端發現服務端證書無效，就會向使用者發出警告，由其選擇是否要繼續通訊。
四、TLS/SSL加密
握手層協商出加密層需要的演算法、演算法的金鑰塊，加密層則進行加密運算和完整性保護。
目前主要有三種加密模式：
- 流密碼加密模式
- 分組加密模式
- AEAD模式
考慮到加密和完整性運算涉及到的安全性問題，建議採用AEAD加密模式。
五、OpenSSL和TLS/SSL的關係
TLS/SSL協議是設計規範，OpenSSL是目前最通用的TLS/SSL協議實現。
OpenSSL是一個底層密碼庫，封裝了所有的密碼學演算法、證書管理、TLS/SSL協議實現。
對於開發者來講，正確地理解並使用底層OpenSSL庫即可。