HTTPS協議詳解

xiaxveliang發表於2020-06-23
HTTP協議

HTTPS協議詳解

從事移動網際網路軟體開發的小夥伴肯定了解：自Android 9.0開始，應用程式的網路請求預設使用https；基本是同期蘋果IOS在應用網路請求方面，也強制使用https禁止http。
這一期間如果你去面試，不瞭解Https的握手過程，都不好意思講工資。
本人一個普通程式設計師，專案期間工期緊張，並未抽出時間詳細瞭解Https網路請求過程中TLS握手過程，因此這件事一直在我的待辦記錄中...
這篇文章以Wireshark抓包，詳細瞭解Https請求中TLS的握手過程 與 客戶端證照校驗過程。

  • HTTPS簡介
  • SSL/TLS握手過程
  • 客戶端 證照校驗

一、HTTPS簡介

HTTPS （Secure Hypertext Transfer Protocol）安全超文字傳輸協議，是一種通過計算機網路進行安全通訊的傳輸協議。
HTTPS 利用 SSL/TLS 來加密資料包，經由 HTTP 進行通訊。
其設計的主要目的是，提供對網站伺服器的身份認證、保護交換資料的隱私與完整性。

https

TLS/SSL

  • SSL（Secure Socket Layer） 1994年由 瀏覽器開發商Netscape公司 率先倡導研發，為資料通訊提供安全支援，開發了最初的幾個版本SSL 1.0、SSL 2.0、SSL 3.0。
  • TLS（Transport LayerSecurity）前身為SSL，1999年從 3.1 開始被 IETF（Internet Engineering Task Force，Internet 工程任務組）標準化並改名，發展至今已經有 TLS 1.0、TLS 1.1、TLS 1.2 三個版本。
    SSL3.0和TLS1.0由於存在安全漏洞，已經很少被使用到；
    TLS 1.3 改動會比較大，目前還在草案階段，目前使用最廣泛的是TLS 1.1、TLS 1.2；

TLS/SSL是介於TCP和HTTP之間的一層安全協議。

https

Http

HTTP（HyperText Transfer Protocol）超文字傳輸協議。
HTTP是一個客戶端（使用者）和服務端之間請求和應答的標準，其最初的設計目的是為了提供一種釋出和接收HTML頁面的方法。

Http協議不是本文重點，感興趣的同學可參考文章：
HTTP 協議詳解
https://blog.csdn.net/xiaxl/article/details/104541274

二、SSL/TLS握手過程

SSL/TLS握手過程用一句話總結就是：用非對稱加密的手段傳遞金鑰，然後用金鑰進行對稱加密傳遞資料。
以下為SSL/TLS握手過程的時序圖：

SSL/TLS握手過程

這裡以客戶端向百度主頁發起Https請求為例，用Wireshark抓包對SSL/TLS握手的各個環節進行介紹，Wireshark抓包示意圖如下圖所示：

Https請求百度主頁WireShark抓包

2.1、Client Hello （ Client——>Server ）

握手第一步是客戶端向服務端傳送 Client Hello 訊息，訊息中包含客戶端的 TSL版本資訊、祕鑰隨機數、加密套件候選列表、壓縮演算法候選列表、擴充套件欄位等資訊，相關資訊通過Wireshark抓包如下：

Client Hello

  • Version : 支援的最高TSL協議版本，從低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2；
  • Random：隨機數 random_C 用於後續的金鑰協商;
  • Session ID：有或者無，有則客戶端傳上一次session的id可以恢復session；
  • Cipher Suite：客戶端支援的密碼演算法列表，供伺服器選擇；
  • Compression Methods：客戶端支援的壓縮演算法列表，用於後續的資訊壓縮傳輸；
  • extensions：擴充套件欄位；
2.2、Server Hello （ Server——>Client ）

服務端向客戶端傳送 Server Hello 訊息：包括服務端選擇使用的TSL協議版本、選擇的加密套件、選擇的壓縮演算法、服務端生成的隨機數等，相關資訊通過Wireshark抓包如下：

Server Hello

  • Version：伺服器選擇的版本；
  • Random：隨機數 random_S 用於後續的金鑰協商;
  • Session ID：有或者無，有則客戶端傳上一次session的id可以恢復session；
  • Cipher Suite：服務端選擇的金鑰演算法；
  • Compression Methods：服務端選擇的壓縮演算法；

到此客戶端和服務端都擁有了兩個隨機數（random_C+ random_S），這兩個隨機數會在後續生成對稱祕鑰時用到。

2.3、Certificate （ Server——>Client ）

服務端下發服務端的公鑰證照給客戶端，相關資訊通過Wireshark抓包如下：

Certificate

  • Certificate 服務端的公鑰證照；
2.4、Server Key Exchange （ Server——>Client ）

該訊息的目的是攜帶金鑰交換的額外資料，該訊息內容對於不同的協商演算法套件會存在差異：

  • 對於使用DHE/ECDHE非對稱金鑰協商演算法的SSL握手，伺服器傳送其使用的DH引數；
  • RSA演算法不會繼續該握手流程（DH、ECDH也不會傳送server key exchange）。

Server Key Exchange

2.5、Server Hello Done （ Server——>Client ）

通知客戶端，服務端已經將所有預計的握手訊息傳送完畢。

Server Hello Done

2.5、證照校驗 （客戶端進行證照校驗）

客戶端拿到服務端的公鑰證照後，需對該證照的合法性進行校驗，校驗內容如下：

  • 證照鏈的可信性；
  • 證照是否吊銷；
  • 證照有效期；
  • 證照域名校驗，核查證照域名是否與當前的訪問域名匹配;

注：
證照的詳細校驗過程將在下文進行詳細介紹

2.6、Client Key Exchange，Change Cipher Spec Protocol，Encrypted Handshake Message （ Client——>Server ）
  • Client Key Exchange
    證照合法性驗證通過之後，客戶端產生隨機數字Pre-master，計算生成祕鑰enc_key（enc_key=Fuc(random_C, random_S, Pre-Master)，將Pre-master與enc_key用證照公鑰加密（非對稱加密演算法）傳送給服務端;
  • Change Cipher Spec Protocol
    客戶端通知服務端後續的通訊都採用協商的通訊金鑰和加密演算法進行加密通訊;
  • Encrypted Handshake Message
    客戶端將之前所有的握手資料（包括接受、傳送）生成摘要，然後用協商好的祕鑰enc_key加密（對稱加密演算法），傳送給對應的服務端；
    服務端收到訊息後，會用祕鑰enc_key解密客戶端的摘要資訊，然後用與客戶端相同的演算法生成服務端摘要資訊，最後對比兩個摘要資訊相同，則驗證通過；

Client Key Exchange，Change Cipher Spec Protocol，Encrypted Handshake Message

2.7、Change Cipher Spec Protocol （ Server——>Client ）

伺服器同樣傳送 Change Cipher Spec Protocol 以告知客戶端後續的通訊都採用協商的金鑰與演算法進行加密通訊;

Change Cipher Spec Protocol

2.8、Encrypted Handshake Message （ Server——>Client ）

服務端也會將握手過程的訊息生成摘要再用祕鑰加密，這是服務端發出的第一條加密訊息;
客戶端接收後會用祕鑰解密，能解出來說明協商的祕鑰是一致的。

Encrypted Handshake Message

2.9、Application Data （ Client——>Server ）

到這裡，雙方已安全地協商出了同一份祕鑰enc_key，所有的應用層資料都會用這個祕鑰加密後再通過 TCP 進行可靠傳輸。

Application Data

2.10 總結

SSL/TLS握手過程：用非對稱加密的手段傳遞金鑰，然後用金鑰進行對稱加密傳遞資料。

三、證照校驗

客戶端驗證服務端下發的證照，主要包括以下幾個方面：

  • 第一，校驗證照是否是受信任的CA根證照頒發機構頒發；
  • 第二，校驗證照是否在上級證照的吊銷列表；
  • 第三，校驗證照是否過期；
  • 第四，校驗證照域名是否一致。
3.1、校驗證照是否是由受信任的CA根證照頒發機構頒發

為了確保客戶端獲取到的服務端公鑰不被篡改，需引入權威的第三方CA機構。
CA機構負責核實公鑰擁有者資訊、頒發“證照(對服務端公鑰進行簽名)”，同時為使用者提供證照驗證服務。

CA機構頒發證照的基本原理為：

  • 服務端生成一對服務端公鑰、服務端私鑰；
  • 服務端將自己的服務端公鑰提供給CA機構；
  • CA機構核實服務端公鑰擁有者資訊（核實申請者提供資訊的真實性，如組織是否存在、企業是否合法、是否擁有域名的所有權等）；
  • CA機構計算服務端公鑰的摘要資訊，利用CA機構的私鑰（CA機構有一對公鑰、私鑰）進行加密，加密後的服務端公鑰即CA機構頒發的“證照”；

客戶端驗證服務端公鑰的基本原理為：

  • Https網路請求過程中，客戶端獲取到服務端的公鑰；
  • 客戶端用儲存在本地的CA機構的公鑰，對 服務端公鑰進行解密，獲取到服務端公鑰的摘要資訊A；
  • 客戶端計算服務端公鑰的摘要資訊B；
  • 對比摘要資訊A與B，相同則證照驗證通過；

CA機構簽發公鑰與客戶端驗證

3.2、校驗證照是否在上級證照的吊銷列表

CA機構能夠簽發證照，同樣也存在機制宣佈以往簽發的證照無效。使用者私鑰丟失，使用者申請讓證照無效等情況，CA機構需要廢棄該證照。
主要存在兩類機制：CRL 與 OCSP。

  • CRL（Certificate Revocation List）
    證照吊銷列表是一個單獨的檔案，該檔案包含了 CA機構 已經吊銷的證照序列號與吊銷日期；
    證照中一般會包含一個 URL 地址 CRL Distribution Point，通知使用者去哪裡下載對應的 CRL 以校驗證照是否吊銷。
    該吊銷方式的優點是不需要頻繁更新，但是不能及時吊銷證照，因為 CRL 更新時間一般是幾天，這期間可能已經造成了極大損失。
  • OCSP（Online Certificate Status Protocol）
    證照狀態線上查詢協議，一個實時查詢證照是否吊銷的方式。
    請求者傳送證照的資訊並請求查詢，伺服器返回正常、吊銷或未知中的任何一個狀態。
    證照中一般也會包含一個 OCSP 的 URL 地址，要求查詢伺服器具有良好的效能。
    部分 CA 或大部分的自籤 CA (根證照)都是未提供 CRL 或 OCSP 地址的，對於吊銷證照會是一件非常麻煩的事情。
3.3、校驗證照是否過期

校驗證照的有效期是否已經過期

3.4、校驗證照域名是否一致

校驗證照域名是否一致：核查證照域名是否與當前的訪問域名匹配。
這裡核驗的是我們請求的域名 www.baidu.com 是否與證照檔案中DNS標籤下所列的域名相匹配；

注：
具體的證照檔案舉例，請檢視第四節 “四、證照舉例” 。

一種錯誤的寫法：

Android 軟體開發中，我們經常會遇到以下程式碼，用來忽略證照的域名驗證，其實這是一種不安全的寫法：

// 對於自簽名證照，用以下程式碼來忽略證照的域名驗證
HostnameVerifier hostnameVerifier = new HostnameVerifier() {
    @Override
    public boolean verify(String urlHostName, SSLSession session) {
		// 忽略證照的域名驗證
        return true;
    }
};

四、證照舉例

這裡以百度的Https證照舉例：

證照舉例

Certificate:
	Data:
	    Version: 3 (0x2)
	    Serial Number:
	        72:58:78:36:6e:9f:56:e8:1d:41:88:48
	Signature Algorithm: sha256WithRSAEncryption
	    Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2
	    Validity
	        Not Before: Apr  2 07:04:58 2020 GMT
	        Not After : Jul 26 05:31:02 2021 GMT
	    Subject: C=CN, ST=beijing, L=beijing, OU=service operation department, O=Beijing Baidu Netcom Science Technology Co., Ltd, CN=baidu.com
	    Subject Public Key Info:
	        Public Key Algorithm: rsaEncryption
	            Public-Key: (2048 bit)
	            Modulus:
	                00:c1:a9:b0:ae:47:1a:d2:57:eb:1d:15:1f:6e:5c:
	                b2:e4:f8:0b:20:db:ea:00:df:29:ff:a4:6b:89:26:
	                4b:9f:23:2f:ec:57:b0:8a:b8:46:40:2a:7e:bc:dc:
	                5a:45:97:4f:ad:41:0e:bc:20:86:4b:0c:5d:55:21:
	                47:e2:31:3c:57:a7:ec:99:47:eb:47:0d:72:d7:c8:
	                16:54:75:ef:d3:45:11:0f:4b:ce:60:7a:46:5c:28:
	                74:ae:8e:1b:be:d8:70:66:7b:a8:93:49:28:d2:a3:
	                76:94:55:de:7c:27:f2:0f:f7:98:0c:ad:86:da:c6:
	                ae:fd:9f:f0:d9:81:32:9a:97:e3:21:ee:04:92:96:
	                e4:78:11:e5:c4:10:0e:10:31:7a:4a:97:a0:eb:c7:
	                9b:c4:da:89:37:a9:c3:37:d7:56:b1:7f:52:c7:d9:
	                26:0a:d6:af:38:16:b1:6d:fb:73:79:b1:68:79:03:
	                90:eb:88:7b:8c:48:91:98:51:a5:07:94:86:a5:78:
	                46:79:8f:58:9b:e9:35:59:a7:f1:7b:57:31:0a:90:
	                cf:24:ce:0d:24:e7:92:b2:6a:e9:e6:96:37:0a:b8:
	                7c:87:2f:74:d2:5c:e8:4b:0a:5f:66:18:a7:41:86:
	                cf:26:a6:08:8e:a5:49:17:92:53:b3:91:a5:cf:53:
	                b0:31
	            Exponent: 65537 (0x10001)
	    X509v3 extensions:
	        X509v3 Key Usage: critical
	            Digital Signature, Key Encipherment
	        Authority Information Access: 
	            CA Issuers - URI:http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt
	            OCSP - URI:http://ocsp2.globalsign.com/gsorganizationvalsha2g2

	        X509v3 Certificate Policies: 
	            Policy: 1.3.6.1.4.1.4146.1.20
	              CPS: https://www.globalsign.com/repository/
	            Policy: 2.23.140.1.2.2

	        X509v3 Basic Constraints: 
	            CA:FALSE
	        X509v3 CRL Distribution Points: 

	            Full Name:
	              URI:http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl

	        X509v3 Subject Alternative Name: 
	            DNS:baidu.com, DNS:baifubao.com, DNS:www.baidu.cn, DNS:www.baidu.com.cn, DNS:mct.y.nuomi.com, DNS:apollo.auto, DNS:dwz.cn, DNS:*.baidu.com, DNS:*.baifubao.com, DNS:*.baidustatic.com, DNS:*.bdstatic.com, DNS:*.bdimg.com, DNS:*.hao123.com, DNS:*.nuomi.com, DNS:*.chuanke.com, DNS:*.trustgo.com, DNS:*.bce.baidu.com, DNS:*.eyun.baidu.com, DNS:*.map.baidu.com, DNS:*.mbd.baidu.com, DNS:*.fanyi.baidu.com, DNS:*.baidubce.com, DNS:*.mipcdn.com, DNS:*.news.baidu.com, DNS:*.baidupcs.com, DNS:*.aipage.com, DNS:*.aipage.cn, DNS:*.bcehost.com, DNS:*.safe.baidu.com, DNS:*.im.baidu.com, DNS:*.baiducontent.com, DNS:*.dlnel.com, DNS:*.dlnel.org, DNS:*.dueros.baidu.com, DNS:*.su.baidu.com, DNS:*.91.com, DNS:*.hao123.baidu.com, DNS:*.apollo.auto, DNS:*.xueshu.baidu.com, DNS:*.bj.baidubce.com, DNS:*.gz.baidubce.com, DNS:*.smartapps.cn, DNS:*.bdtjrcv.com, DNS:*.hao222.com, DNS:*.haokan.com, DNS:*.pae.baidu.com, DNS:*.vd.bdstatic.com, DNS:click.hm.baidu.com, DNS:log.hm.baidu.com, DNS:cm.pos.baidu.com, DNS:wn.pos.baidu.com, DNS:update.pan.baidu.com
	        X509v3 Extended Key Usage: 
	            TLS Web Server Authentication, TLS Web Client Authentication
	        X509v3 Authority Key Identifier: 
	            keyid:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C

	        X509v3 Subject Key Identifier: 
	            ......

五、參考

TSL：
https://tools.ietf.org/html/rfc5246

SSL/TSL 原理：
https://www.cnblogs.com/chenjingquan/p/10531305.html

TLS/SSL握手過程
https://blog.csdn.net/hherima/article/details/52469674

========== THE END ==========

wx_gzh.jpg

相關文章