HTTPS實作原理分析-有解無憂

概述

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

對稱加密
非對稱加密

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

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 傳給服務端的程序如下圖所示：