圖文詳解 HTTPS 工做原理

時間 2020-05-26

標籤圖文詳解 https 原理简体版

原文原文鏈接

原文：https://www.toutiao.com/a6821...git

目標讀者：理解HTTP協議，對稱和非對稱加密，想要了解HTTPS協議的工做原理算法

讀完本文，你能明白segmentfault

什麼是HTTPS，TLS(SSL)，TLS和HTTPS是什麼關係
什麼是證書和數字簽名，它們是如何傳遞信任的
HTTPS有什麼樣的功能，它是如何實現這樣的功能的

簡介

HTTPS，也稱做HTTP over TLS。TLS的前身是SSL，TLS 1.0一般被標示爲SSL 3.1，TLS 1.1爲SSL 3.2，TLS 1.2爲SSL 3.3。本文着重描述TLS協議的1.2版本瀏覽器

下圖描述了在TCP/IP協議棧中TLS(各子協議）和HTTP的關係安全

Credit: Kaushal Kumar Panday From: SSL Handshake and HTTPS Bindings on IIS

其中Handshake protocol，Change Ciper Spec protocol和Alert protocol組成了SSL Handshaking Protocols。服務器

HTTPS和HTTP協議相比提供了網絡

數據完整性：內容傳輸通過完整性校驗
數據隱私性：內容通過對稱加密，每一個鏈接生成一個惟一的加密密鑰
身份認證：第三方沒法僞造服務端（客戶端）身份

其中，數據完整性和隱私性由TLS Record Protocol保證，身份認證由TLS Handshaking Protocols實現。app

總覽

使用RSA算法的SSL握手過程是這樣的less

Source: Keyless SSL: The Nitty Gritty Technical Details

[明文] 客戶端發送隨機數client_random和支持的加密方式列表
[明文] 服務器返回隨機數server_random ，選擇的加密方式和服務器證書鏈
[RSA] 客戶端驗證服務器證書，使用證書中的公鑰加密premaster secret 發送給服務端
服務端使用私鑰解密premaster secret
兩端分別經過client_random，server_random 和premaster secret 生成master secret，用於對稱加密後續通訊內容

證書（Digital certificate）

那麼什麼是證書呢？dom

證書中包含什麼信息

證書信息：過時時間和序列號
全部者信息：姓名等
全部者公鑰

爲何服務端要發送證書給客戶端

互聯網有太多的服務須要使用證書來驗證身份，以致於客戶端（操做系統或瀏覽器等）沒法內置全部證書，須要經過服務端將證書發送給客戶端。

客戶端爲何要驗證接收到的證書

中間人攻擊

客戶端<------------攻擊者<------------服務端        
         僞造證書            攔截請求

客戶端如何驗證接收到的證書

爲了回答這個問題，須要引入數字簽名(Digital Signature)。

+---------------------+
| A digital signature |
|(not to be confused  |
|with a digital       |
|certificate)         |            +---------+              +--------+
| is a mathematical   |----哈希--->| 消息摘要  |---私鑰加密--->| 數字簽名 |
|technique used       |            +---------+              +--------+
|to validate the      |
|authenticity and     |
|integrity of a       |
|message, software    |
|or digital document. |
+---------------------+

將一段文本經過哈希（hash）和私鑰加密處理後生成數字簽名。

假設消息傳遞在Bob，Susan和Pat三人之間發生。Susan將消息連同數字簽名一塊兒發送給Bob，Bob接收到消息後，能夠這樣驗證接收到的消息就是Susan發送的

+---------------------+
| A digital signature |
|(not to be confused  |
|with a digital       |
|certificate)         |            +---------+
| is a mathematical   |----哈希--->|  消息摘要 |
|technique used       |            +---------+
|to validate the      |                 |
|authenticity and     |                 |
|integrity of a       |                 |
|message, software    |                 對
|or digital document. |                 比
+---------------------+                 |                                                           | 
                                        |          
          +--------+               +---------+          
          | 數字簽名 |---公鑰解密--->|  消息摘要 | 
          +--------+               +---------+

固然，這個前提是Bob知道Susan的公鑰。更重要的是，和消息自己同樣，公鑰不能在不安全的網絡中直接發送給Bob。

此時就引入了證書頒發機構（Certificate Authority，簡稱CA），CA數量並很少，Bob客戶端內置了全部受信任CA的證書。CA對Susan的公鑰（和其餘信息）數字簽名後生成證書。

Susan將證書發送給Bob後，Bob經過CA證書的公鑰驗證證書籤名。

Bob信任CA，CA信任Susan 使得 Bob信任Susan，信任鏈（Chain Of Trust）就是這樣造成的。

事實上，Bob客戶端內置的是CA的根證書(Root Certificate)，HTTPS協議中服務器會發送證書鏈（Certificate Chain）給客戶端。

TLS協議

TLS協議包括TLS Record Protocol和TLS Handshake Protocol。總覽中的流程圖僅涉及到TLS Handshake Protocol。

TLS Record Protocol

在TLS協議中，有四種子協議運行於Record protocol之上

Handshake protocol
Alert protocol
Change cipher spec protocol
Application data protocol

Record protocol起到了這樣的做用

在發送端：將數據（Record）分段，壓縮，增長MAC(Message Authentication Code)和加密
在接收端：將數據（Record）解密，驗證MAC，解壓並重組

值得一提的是，Record protocol提供了數據完整性和隱私性保證，但Record類型（type）和長度（length）是公開傳輸的

Record Protocol有三個鏈接狀態(Connection State)，鏈接狀態定義了壓縮，加密和MAC算法。全部的Record都是被當前狀態（Current State）肯定的算法處理的。

TLS Handshake Protocol和Change Ciper Spec Protocol會致使Record Protocol狀態切換。

empty state -------------------> pending state ------------------> current state            
            Handshake Protocol                Change Cipher Spec

初始當前狀態（Current State）沒有指定加密，壓縮和MAC算法，於是在完成TLS Handshaking Protocols一系列動做以前，客戶端和服務端的數據都是明文傳輸的；當TLS完成握手過程後，客戶端和服務端肯定了加密，壓縮和MAC算法及其參數，數據（Record）會經過指定算法處理。

其中，Record首先被加密，而後添加MAC（message authentication code）以保證數據完整性。

TLS Handshaking Protocols

Handshakeing protocols包括Alert Protocol，Change Ciper Spec Protocol和Handshake protocol。本文不會詳細介紹Alert Protocol和Change Ciper Spec Protocol。

使用RSA算法的握手過程是這樣的（已在總覽中提到）

Source: Keyless SSL: The Nitty Gritty Technical Details

客戶端和服務端在握手hello消息中明文交換了client_random和server_random ，使用RSA公鑰加密傳輸premaster secret ，最後經過算法，客戶端和服務端分別計算master secret。其中，不直接使用premaster secret 的緣由是：保證secret的隨機性不受任意一方的影響。

除了使用RSA算法在公共信道交換密鑰，還能夠經過Diffie–Hellman算法。Diffie–Hellman算法的原理是這樣的

By Original schema: A.J. Han Vinck, University of Duisburg-Essen SVG version: Flugaal [Public domain], via Wikimedia Commons

使用Diffie–Hellman算法交換premaster secret 的流程

Source: Keyless SSL: The Nitty Gritty Technical Details

小結

TLS Handshaking Protocols協商了TLS Record Protocol使用的算法和所需參數，並驗證了服務端身份；TLS Record Protocol在協商後保證應用層數據的完整性和隱私性。

TLS Handshaking Protocol的核心是在公開信道上傳遞premaster secret。

Q&A

爲何傳輸內容不直接使用非對稱加密？

性能

HTTPS能保證正常鏈接？

There are a number of ways in which a man-in-the-middle attacker can attempt to make two entities drop down to the least secure method they support.

攻擊者甚至能夠直接丟棄雙方的數據包

服務端如何驗證客戶端身份？

經過Client Certificate

This message conveys the client’s certificate chain to the server; the server will use it when verifying the CertificateVerify message (when the client authentication is based on signing) or calculating the premaster secret (for non-ephemeral Diffie- Hellman). The certificate MUST be appropriate for the negotiated cipher suite’s key exchange algorithm, and any negotiated extensions.

Alert protocol有什麼做用？

Closure Alerts：防止Truncation Attack

In a truncation attack, an attacker inserts into a message a TCP code indicating the message has finished, thus preventing the recipient picking up the rest of the message. To prevent this, SSL from version v3 onward has a closing handshake, so the recipient knows the message has not ended until this has been performed.

Error Alerts：錯誤處理

master secret是如何計算的

master_secret = PRF(pre_master_secret, "master secret",  
                    ClientHello.random + ServerHello.random)                      
                    [0..47];

加密，壓縮和MAC算法參數是如何計算的

Handshaking Protocols使得客戶端和服務端交換了三個參數：client_random，server_random 和master_secret，經過如下算法生成算法所須要的參數

To generate the key material, compute  

key_block = PRF(SecurityParameters.master_secret, 
         "key expansion",    
         SecurityParameters.`server_random ` + 
         SecurityParameters.`client_random`);

until enough output has been generated.  Then, the key_block ispartitioned as follows:  
client_write_MAC_key[SecurityParameters.mac_key_length]  
server_write_MAC_key[SecurityParameters.mac_key_length]  
client_write_key[SecurityParameters.enc_key_length]  
server_write_key[SecurityParameters.enc_key_length]  
client_write_IV[SecurityParameters.fixed_iv_length]  
server_write_IV[SecurityParameters.fixed_iv_length]

The master secret is expanded into a sequence of secure bytes, which is then split to a client write MAC key, a server write MAC key, a client write encryption key, and a server write encryption key

使用Diffie-Hellman算法的TLS握手細節

Source: https://cipherstuff.wordpress...

拓展閱讀

Keyless
Let’s Encrypt
Session resume
證書Revoke

參考連接

TLS1.2規範：The Transport Layer Security (TLS) Protocol Version 1.2
PKI規範：Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
證書和數字簽名：What is a Digital Signature?
TLS Handshake：Keyless SSL: The Nitty Gritty Technical Details

若有錯誤或其它問題，歡迎小夥伴留言評論、指正。若有幫助，歡迎點贊+轉發分享。

歡迎你們關注民工哥的公衆號：民工哥技術之路