HTTPS詳解-加密演算法（二）完

WeiZhao_111發表於2018-07-23

HTTP加密演算法

來自：Weizhao的部落格

概述

在上已一節中介紹了兩種加密方法

對稱加密
非對稱加密

其中對稱加密效能高，但是有洩露金鑰的風險，而非對稱加密相反，加密效能較差，但是金鑰不易洩露，那麼能不能把他們進行一下結合呢？

HTTPS採用混合加密

HTTPS經由HTTP進行通訊，但利用SSL/TLS來加密資料包,而SSL/TLS的加密方式就是採用了對稱加密與非對稱加密的結合。

SSL/TLS考慮到非對稱加密的效能較低，所以在初始協商對稱加密金鑰時，使用了非對稱加密，當對稱加密金鑰協商完成後，則後續所有的通訊，全部採用對稱加密進行通訊。

但是這種方式也有一些問題，如下

無法證明公開金鑰就是真實伺服器的公開金鑰

比如與B伺服器進行通訊，怎麼確認公開金鑰是B伺服器的，後續在公開金鑰傳輸途中已經被替換了，但是卻發現不了。

由於任何人都可以訪問伺服器，所以不可能一一把公鑰告訴他們，那麼能不能提供一個公鑰下載的地方讓客戶機訪問伺服器時先下載公鑰，但是下載公鑰的地址也有可能是假的，不可取。

那麼有沒有更好的方式，既能安全的獲取公鑰又能確保訪問的伺服器是真實的？答案：由數字證書認證機構頒發（CA）公開金鑰證書

數字證書認證機構是客戶端和伺服器端都可以信賴的第三方機構，VeriSign就是一家數字證書機構。流程如下：

企業向證書機構提出公開金鑰申請。
證書機構首先對公司身份進行核實，核實通過去，使用自己的私鑰對企業伺服器的公開金鑰進行數字簽名，並把簽名資訊繫結在公鑰證書裡下發給企業。
拿到證書的客戶端對證書的簽名進行校驗，驗證通過，即可確認：
1. 伺服器的公開金鑰是值得信賴的
2. 根據數字證書籤發機構是真實有效的數字證書認證機構。

這裡應該有人好奇，證書籤發機構的公鑰是怎麼傳到客戶端的？瀏覽器在釋出時，已經包含了主流的認證的機構的公開金鑰了，所以是不需要傳輸的。

HTTPS通訊流程

上圖大致描述了 SSL/TLS 的握手過程,具體細節如下：

Client Hello

握手第一步是客戶端向服務端傳送 Client Hello 訊息，這個訊息裡包含了一個客戶端生成的隨機數 Random1、客戶端支援的加密套件（Support Ciphers）和 SSL Version 等資訊。通過 Wireshark 抓包，我們可以看到如下資訊：
Server Hello

第二步是服務端向客戶端傳送 Server Hello 訊息，這個訊息會從 Client Hello 傳過來的 Support Ciphers 裡確定一份加密套件，這個套件決定了後續加密和生成摘要時具體使用哪些演算法，另外還會生成一份隨機數 Random2。注意，至此客戶端和服務端都擁有了兩個隨機數（Random1+ Random2），這兩個隨機數會在後續生成對稱祕鑰時用到。
Certificate

這一步是服務端將自己的證書下發給客戶端，讓客戶端驗證自己的身份，客戶端驗證通過後取出證書中的公鑰。
Server Hello Done

Server Hello Done 通知客戶端 Server Hello 過程結束。

Client Key Exchange

客戶端收到服務端傳來的證書後，先從 CA 驗證該證書的合法性，驗證通過後取出證書中的服務端公鑰，再生成一個隨機數 Random3，再用服務端公鑰非對稱加密 Random3生成 PreMaster Key。

Client Key Exchange 就是將這個 key 傳給服務端，服務端再用自己的私鑰解出這個 PreMaster Key 得到客戶端生成的 Random3。至此，客戶端和服務端都擁有 Random1 + Random2 + Random3，兩邊再根據同樣的演算法就可以生成一份祕鑰，握手結束後的應用層資料都是使用這個祕鑰進行對稱加密。為什麼要使用三個隨機數呢？這是因為 SSL/TLS 握手過程的資料都是明文傳輸的，並且多個隨機數種子來生成祕鑰不容易被暴力破解出來。客戶端將 PreMaster Key 傳給服務端的過程如下圖所示：