從加密解密演進看 HTTPS 通訊（下）——HTTPS 通訊流程

前情提要

上一篇文章簡單描述了加密解密的演進歷史，若是對這部分不感興趣的小夥伴其實能夠跳過那篇文章，不過在講以前我仍是要先作一些知識點鋪墊工做，避免文中遇到這些名詞時沒頭緒。

加密主要是分紅對稱加密和非對稱加密，這裏會涉及到這些知識點：

• 鑰匙，能夠理解爲原文密文的對應替換規則；
• 對稱加密，指的是加密和解密過程當中使用的鑰匙都是同一把鑰匙，這樣雖然加密解密後信息安全傳輸獲得保障，可是存在一個嚴重問題就是對稱加密使用到的鑰匙要如何傳遞給對方；
• 非對稱加密，指的是加密和解密過程須要使用到的鑰匙是兩把不一樣的鑰匙，公開的那把被稱爲公鑰，本身持有那把被稱爲私鑰，因此我只須要將公鑰開放出去，別人經過使用個人公鑰對信息進行加密，等我收到消息時再用本身的私鑰進行解密，這樣我就能夠看到原文內容了，這個過程既完成了信息安全傳輸，並且還避免了對稱加密那把鑰匙傳輸的問題；
• 簽名，非對稱加密不只能夠公鑰加密私鑰解密，還能夠私鑰加密公鑰解密，不過因爲這個私鑰只有本身持有，因此這個過程也叫簽名，而公鑰解私鑰的過程也被稱爲驗籤，爲何叫簽名呢，實際上是由於私鑰只有我本身持有，因此能夠利用這個特性對你進行身份認證的，就像是我給你寫了張欠條而後簽了本身的名字，由於筆跡並非那麼容易僞造的，而不可僞造也就能夠用來進行身份驗證；
• 效率問題，非對稱加密因爲涉及到大量數學運算，因此加密解密效率相比對稱加密是低的；

HTTPS 通訊流程

講 HTTPS 以前咱們先來看看爲何 HTTP 不能知足咱們的需求，它都存在哪些問題？當咱們瞭解了它的缺點，咱們也就更容易理解，爲何 HTTPS 的通訊過程要像如今這樣設計了。

HTTP 通訊的四類問題

HTTP 通訊的四類問題：

• 攔截（機密性），傳輸信息能夠被中間人攔截，從而致使數據泄漏；
• 篡改（完整性），基於攔截，中間人能夠對數據進行了修改，從而沒辦法保證數據完整；
• 假裝（身份驗證），兩我的通訊時，任何一方均可能被中間人冒名頂替；
• 否定（不能否認），因爲存在假裝，因此其中一方能夠僞裝沒有收到對方消息或對方收到的消息不是本身發的；

那咱們可否利用已有知識解決這些問題呢？答案是基本上能夠，讓咱們來看看這些問題具體該如何解決：

• 機密性可使用對稱加密或非對稱加密能夠解決這個問題，只是還有一些區別：
  • 對稱加密速度快效率高，非對稱加密速度慢（由於涉及到大量數據運算）效率低；
  • 對稱加密雖然過程是安全的，可是信息加密傳輸以前的密鑰傳輸是一個很大的問題；
• 完整性能夠經過摘要算法來完成；
  • 它會把任意長度的數據壓縮成固定長度，且生成的是獨一無二的摘要信息，就像指紋同樣；
  • 會存在摘要信息衝突的可能性，因此要看具體摘要算法自己和信息長度；
  • 具備單向性（不可逆）和雪崩效應（微小修改都會引發劇烈變化）；
  • 完整性仍是要創建在機密性之上，由於若是摘要信息是明文的仍是有可能被修改；
• 身份驗證 / 不能否認：能夠利用非對稱加密的簽名特性來同時完成，這裏還有知識點就是證書（後面仔細講），其實當你身份驗證完成後其實你就無法對發送的消息進行否定了，由於別人沒法僞造；

那既然咱們知道了 HTTP 的信息傳輸過程當中存在的這些問題，那咱們接下來就進入正題，看看 HTTPS 如何解決掉這些問題。

HTTPS 介紹

瞭解通訊流程以前，還須要先對 HTTPS 簡單作個介紹，爲何 HTTPS 能夠保障安全，它和 HTTP 到底有什麼區別和聯繫？

其實 HTTPS = HTTP over SSL / TLS，這樣看的話，其實它和 HTTP 的區別就是在於多了 SSL / TLS，因此 HTTPS 的密鑰協商、傳遞、加密解密也確定都是由 SSL / TLS 完成的。至於 SSL 和 TLS 的區別實際上是 TLS 是 SSL 的升級版，一開始 HTTPS 剛出來的時候安全層是 SSL，後來協議標準化，就在 SSL 的基礎上進行優化修改而且將其更名爲 TLS。

本來 HTTP 的數據是會扔給 TCP 進行處理髮送的，而 HTTPS 中成了 HTTP 數據扔給 SSL / TLS 加密處理，而後在由 SSL / TLS 扔給 TCP，對方收到後也是 TCP 扔給 SSL / TLS 進行解密，最後扔給 HTTP。如今像是在這二者之間插入了一層，因此我通常也稱 SSL / TLS 爲安全層。

HTTP -> TCP（HTTP）
HTTP -> TLS -> TCP（HTTPS）
複製代碼

介紹完了什麼是 HTTPS 後，若是隻用一句話歸納它，其實 HTTPS 的本質就是用非對稱加密協商出一套對稱加密密鑰。而後數據的傳遞都是經過對稱加密去作。這樣既保障了安全又保障了效率。

保障效率是由於後續真正的數據傳輸實際上是經過對稱加密來完成的，相比之下，非對稱加密因爲涉及到到大量運算，執行起來比對稱加密要慢，而保障安全是由於對稱加密密鑰的傳輸是經過非對稱加密的方式解決掉的。

HTTPS 通訊流程

下面就來看看 HTTPS 的通訊流程吧。

先來看下面這張圖：

TLS 或 HTTP 下層都是 TCP，因此無論怎樣咱們都須要先經過 TCP 三次握手來創建鏈接，而後再在這個鏈接基礎上，進行 TLS 的握手。粗略的看話，我以爲 TLS 握手主要包括如下內容：

• 客戶端請求創建 TLS 鏈接；
• 服務器返回信息和發回證書；
• 客戶端驗證服務器證書；
• 客戶端信任服務器後，開始與服務器協商對稱加密密鑰；
• 驗證密鑰是否可用和使用對稱密鑰開始通訊；

若是仔細來看的話，我建議看着下面這張圖：

那讓咱們再來詳細的展開如下這個 TLS 的握手流程：

• Client Hello，也就是告訴對方我想和你創建 TLS 鏈接，主要是協商加密方案和發送隨機數；
  • 附加內容列一下：
    • TLS 版本；
    • 可選的對稱加密算法；
    • 可選的非對稱加密算法；
    • 可選的 Hash 算法（信息完整性計算時使用）；
    • 客戶端隨機數（客戶端和服務端的隨機數都是用來後續對稱密鑰生成的）；
• Service Hello，服務端會返回確認後的加密方案和隨機數；
  • 附加信息也都是確認信息，以下：
    • 確認的 TLS 版本；
    • 確認的對稱加密算法；
    • 確認的非對稱加密算法；
    • 確認的 Hash 算法；
    • 服務器隨機數；
• 接下來服務器還會把證書發送過來，用於客戶端進行驗證服務端的身份；
  • 意義在於服務器的公鑰在證書裏，接下來用於讓客戶端拿驗證好公鑰發消息給服務端；
  • 具體驗證細節和證書是什麼會後面講；
  • 若是是雙向驗證客戶端也須要把本身證書發給服務端；
• 客戶端生成 pre-master 隨機數，並用剛纔驗證過沒問題的證書裏的服務器公鑰進行加密，傳輸給服務器；
  • 兩邊經過這三個隨機數（客戶端隨機數、服務端隨機數以及剛生成的 pre-master）進行對稱加密的密鑰；
  • 雖然客戶端隨機數、服務端隨機數是明文發送的，可是 pre-master 是使用服務端公鑰進行傳輸的，因此就算別人拿到前兩個隨機數，別人仍是不知道實際的對稱密鑰是什麼，由於中間人沒有拿到 pre-master，就無法推算出真正的對稱加密密鑰；
  • 若是隻是單向證書驗證，其實只須要客戶端拿到服務器證書裏面的公鑰進行加密，而後後將加密後消息傳遞給服務端便可，但雙向驗證時，就須要客戶端不只用服務端的公鑰加密，還須要用本身私鑰對加密後的內容簽名，從而確保安全和身份驗證功能，這樣服務端拿到內容先驗籤再解密了；
  • 這裏的計算會生成四個東西：
    • 客戶端加密密鑰，客戶端發過去的東西用這個加密，而後服務端收到後用它解密；
    • 服務端加密密鑰，服務端發過去的東西用這個加密，而後客戶端收到後用它解密；
      • 上面兩個爲啥這麼設計？爲了區分是誰發的，也防止消息被扔回去；
      • 若是都使用同一把鑰匙那中間人雖然看不懂，可是能夠扔回去，你也不知道這消息到底是來自本身這邊的仍是服務端那邊的；
    • 客戶端 Mac secret；
    • 服務端 Mac secret；
      • Mac secret，是 HMAC（基於 Hash 消息認證碼） secret，用來驗證消息是否被篡改過，和簽名的做用很是像，能夠驗證消息的完整性和來源（驗證來源是由於兩邊的 HMAC 不同）；
• 客戶端通知：將使用加密通訊；
• Finished（並非真的發 Finished 這個幾個字母，是個信息指代）；
  • 這兩步也是爲了驗證一下，咱們剛纔商量好的對稱密鑰行不行，我發給你你能不能解開；
  • 把以前全部發送消息作一個摘要，而後加密，發過去讓服務器驗證；
• 服務端通知：將使用加密通訊；
• Finished；
  • 這兩步只是上面的反過來，這個也驗證完就說明兩邊發的對方都能看懂了，能夠開始正式通訊了；

這就是我理解的 HTTPS 的通訊流程了，不過剛纔上面還缺失了重要一環也是證書驗證的內容，下面來主要講講證書驗證。

證書驗證

回想一下咱們最開始提到的若是愛麗絲想要和鮑勃使用非對稱加密進行安全通訊的話，那就必須先讓愛麗絲拿到鮑勃的公鑰才行，有什麼辦法能夠拿到對方的公鑰嗎？

• 鮑勃把公鑰放在網站上別人去拿；
• 愛麗絲和鮑勃進行通訊時，鮑勃發給愛麗絲；

若是仔細想一想的話這兩種方式其實都有問題，前者若是中間人伊芙引導你訪問了錯誤的網站就會致使你拿到錯誤的公鑰，然後者伊芙可能在大家公鑰傳輸的過程當中對信息進行攔截和篡改，因此愛麗絲想要拿到正確的鮑勃的公鑰並不容易。

那這個問題有解決方案嗎？就是經過非對稱加密的簽名來處理，可是鑑於無法拿到正確的鮑勃的公鑰因此無法讓鮑勃進行簽名發送過來，這時就須要一個第三方權威機構，咱們都信任它，而它會用本身的私鑰對鮑勃的公鑰進行簽名，而後咱們只須要拿到這個第三方權威機構的公鑰進行驗籤便可。

回到實際場景中來，這個第三方機構，就是證書頒發機構，也被稱爲 CA（後面也都簡寫爲 CA），若是服務端想讓 CA 給它頒發證書（信用背書），就會把本身的公鑰和身份信息發給 CA，CA 驗證沒問題後，生成證書信息，而且 CA 會對證書信息作一個摘要算法，就像提取指紋信息同樣，而後會對計算出來的 Hash 值進行簽名，最後打包下發。

先來粗略看下證書裏面都會包含什麼信息：

• 要背書的公鑰；
• 證書全部者；
• 證書有效期；
• 證書發佈機構；
• 簽名算法；
• ...；

那咱們該如何驗證簽名呢？

• 先對服務端發來的證書用指定的摘要算法進行摘要，獲得指紋 P1；
• 而後使用這個證書頒發 CA 的公鑰對他的數字簽名進行驗籤，獲得指紋 P2；
• 最後看看 P1 和 P2 是否相等，相等就說明證書沒有被竄改過，若是不相同就說證書被人篡改過，由於 P2 是沒法僞造的，CA 的簽名時使用的私鑰是隻有 CA 本身才有；

但你可能會問，這個過程好像只是驗證了給證書籤名時的 CA 私鑰和咱們拿到的 CA 公鑰是對的上的，那若是 CA 證書下發過程自己就問題怎麼辦呢？ 我怎麼能確認給這個服務端背書的 CA 是否可信呢？

要回答這個問題其實並不難，就是讓那個 CA 在找別的更大的更可信的 CA 給他作信用背書，直到找到背後那幾個全球最大的 CA 機構，這些 CA 機構也被稱爲 root CA，這些 CA 就已是咱們無條件要相信的了，這就像你能夠不相信同事告訴你的公司消息，可是同事告訴你這個消息是組長告訴個人，你去問了組長仍是不相信，組長說這個是經理告訴個人，你去問了經理仍是不相信，經理說這個是老闆剛發的公司消息，最終你去問了老闆並確認了消息，這時這條信任鏈就已經完整構建起來了。

因此給服務端下發證書的 CA（簡稱 CA L），它的公鑰實際上是另外一個更大 CA（簡稱 CA H）用本身的私鑰給它簽名的，也就是 CA H 會根據 CA L 提供行公鑰和身份信息給它頒發證書，而後這樣遞歸下去，直到咱們剛剛說的 root CA。

因此驗證的順序也像圖中這樣，可能看圖更好理解，我要驗證服務端證書就去找給中介 CA 拿它的公鑰進行驗籤（由於服務端證書是中介 CA 下發的），而中介 CA 證書驗證又要去找 root CA 拿它的公鑰進行驗證（同理中介 CA 的證書是 root CA 下發的），那麼 root CA 的公鑰在哪裏呢？通常在操做系統裏面都會有各大 root CA 的信息，固然瀏覽器或者某些軟件（好比支付寶）裏也會有。這時我拿到了 root CA 的公鑰信息，而後對中介 CA 證書進行驗證（證書驗證過程上面已經講到了），驗證完成後拿到中介 CA 的公鑰再對服務端證書進行驗證，這樣若是都沒問題，就說明整條信任鏈是通的，而我也能夠放心拿服務端證書裏的公鑰和對方進行非對稱加密通訊了。

補充

• 服務端返回的是一個證書鏈，而後和你本地的根證書造成一個完整的驗證鏈；

• root CA 的公鑰是在操做系統裏或者軟件裏，根證書沒有上層機構再爲其自己做數字簽名，因此都是自簽證書；
• 自簽名證書就給人一種感受，我就是我，你愛信不信；
• 證書驗證能夠是單向的也能夠雙向的，要看業務需求；
• 爲何 TLS 會有三個隨機數？
  • TLS 設計者考慮的很周到，不相信「僞隨機「，爲了保障更加隨機，就把三個隨機數很合起來了；
• 只有你擁有對應域名，你才能對其申請證書；
• 再附上一張更詳細圖：

總結

到這裏 HTTPS 的通訊流程也就說完了。

若是隻用一句話總結 HTTPS 就是它的本質是經過非對稱加密協商出一套對稱密鑰，然後續真正數據都是使用對稱加密進行通訊。

這裏面的最難搞懂的點可能就是爲何要有證書和證書驗證過程。

說多了都是淚，但願看到這裏以後 HTTPS 對你來講就不是什麼難理解的事情了。

感謝

以上內容參考了扔物線的 HenCoder Plus、極客時間的《趣談網絡協議》、《透視 HTTP 協議》、《全棧工程師修煉指南》及 HTTPS 相關維基百科。

尤爲是那兩張很全的 HTTPS 流程圖都是出自極客時間專欄，黑白的那種出自《趣談網絡協議》，而最後那張彩色的出自《透視 HTTP 協議》。

最後的最後

若是你以爲我寫不錯，那就經過點贊，點贊，還 tm 是點讚的方式給我反饋吧，感謝你的支持。