參考: https://blog.csdn.net/kefengwang/article/details/81219121
RSA非對稱加密 公鑰加密算法
明文 + 加密算法 + 私鑰 => 密文
密文 + 解密算法 + 公鑰 => 明文
對於數據交換雙方, 都擁有自身的公鑰和私鑰, 私鑰都爲自己私藏, 公鑰都向對方公開
同樣一個數據, 發送方使用自身的私鑰加密, 接收方收到後可以用發送方的公鑰解密
缺點: 加密和解密花費時間長、速度慢, 只適合對少量數據進行加密 主要算法有:
RSA、Elgamal、Rabin、D-H、ECC等
https爲了兼顧安全與效率, 同時使用了對稱加密和非對稱加密
RNc=Random Number of Client
RNs=Random Number of Server
PMS=Pre Master Secret
MS=Master Secret
1.雙方協商交互參數
客戶端 --發送隨機數RNc–> 服務端
客戶端 <–發送隨機數RNs– 服務端
協商使用的SSL/TLS協議版本、加密算法
2.雙方交換並驗證證書
服務端: 發送服務端證書, 並索要客戶端證書
客戶端: 收到服務端證書後, 驗證其身份有效性, 取出服務端公鑰
客戶端: 向服務端發送客戶端證書(證書中包含客戶端公鑰)
服務端: 收到客戶端證書後, 驗證其身份真實性
3.雙方生成"主密鑰" (非對稱加密)
客戶端對隨機數值(RNc+RNs)作哈希, 並用自己的公鑰私鑰、對方公鑰簽名, 併發送給服務端
服務端以同樣算法(自己的公鑰私鑰、對方公鑰), 檢查客戶端發送的哈希簽名RNc+RNs
客戶端生成隨機數PMS並用客戶端私鑰加密, 再發送給服務端
服務端使用客戶端公鑰解密取得PMS, 至此雙方有相同的PMS
雙方使用D-H密鑰交換算法生成相同的"主密鑰"(MS: RNc+RNs+PMS)
4.完成握手並開始交互 (對稱加密)
雙方使用"主密鑰"作爲數據傳輸時對稱加密使用的密鑰
整個驗證過程, 折騰了半天, 其實是爲了安全地得到一個雙方約定的對稱加密密鑰
https協議爲什麼通信時使用對稱加密, 而不使用非對稱加密?
非對稱加密計算量大、比較耗時, 而對稱加密耗時少
對稱加密的密鑰只在這次連接中斷前有效, 從而保證數據傳輸安全