使用wireshark分析HTTPS流程的創建

時間  2019-11-13
標籤 使用 wireshark 分析 https 流程 創建 简体版
原文   原文鏈接

1、概要

爲了網站以及用戶的安全性，如今不少的網站都是https，你們都知道tcp經過三次握手創建鏈接，而且還有不少的同窗對https鏈接創建的流程不太明白，包括我本身，經過藉助於wireshark這種抓包工具，咱們能夠嘗試着瞭解一下大概的流程。nginx

（圖1）git

本圖是客戶端（10.0.45.103）訪問服務端（114.215.88.85）經過wireshark抓包顯示出來的雙方交互數據，訪問是經過https訪問服務器上的一臺nginx服務器服務。請關注第一列的No。下文中不少時候會用no表示一次交互。算法

圖中能夠很明顯的看出tcp的三次握手以及以後的TLS加密流程的創建。json

2、tcp的三次握手

經過流程圖能夠看出（也能夠看圖1 的19368到19370這三個編號），首先客戶端向服務端發起一個SYN的請求，序號(Seq)爲0，確認號（ACK）也爲0，這表明是本次是由客戶端發起的首次請求。本次請求的數據長度爲0瀏覽器

而後服務端給客戶端響應，此時服務端的Seq也是0，表明這是服務端的第一次迴應，而且給客戶端說，你的請求我已經收到了（ACK=1），安全

最後返還給客戶端之後，客戶端的序號+1，而且對服務端的響應作出確認，最後回給服務端，此時ACK=1，Seq=1服務器

tcp的握手過程創建成功。session

3、ssl鏈接的創建

經過以上能夠看出，SSL也是創建在TCP的基礎上的，通過tcp的三次握手，接下來纔是加密信道的創建。dom

客戶端和服務端創建安全鏈接大體通過如下幾個步驟tcp

  1. 客戶端：ClientHello
  2. 服務端：Server Hello，Server certificate，Server Exchange，Server Hello Done
  3. 客戶端：client Exchange
  4. 客戶端：Application Data
  5. 服務端：New Session
  6. 服務端：Application Data

接下來看這幾個步驟中具體的每個步驟傳輸的內容

ClientHello

client首先給服務端打招呼，對服務端說hello

應用層沒什麼特別的

客戶端向服務端發送202個字節的數據，而且客戶端此時的 seq num 爲1 ，tcp三次握手已經經過了，因此客戶端ack num 確認的是服務端的tcp的最後一次信息。因爲此次發送的長度是202個字節，因此給服務端說，下一個字節序列號是從203開始的。

標誌位爲ACK和PSH

可是此次多了一個 Secure Socket layer層。協議使用的時候，用的是Handshake Protocol，給服務端發消息ClientHello

詳細的信息以下：

Secure Socekts layer層使用的是版本是TLS  1.0

HandShake Type的類型，是客戶端打招呼 client hello

HandShake protocol 協議使用的是TLS 1.2

發送的信息還有客戶端在本地生成的隨機碼（Random）

而後客戶端聲明本身所支持的加密套件（Cipher Suites）這個客戶端支持15種加密套件

加密套件中代表了使用的對稱加密算法，非對稱加密算法，摘要算法以及使用的是TLS或者是SSL

還有一些其餘的信息

第一行指明是否進行了壓縮以及使用的壓縮算法，第二行null代表未進行壓縮，以及選用相關的壓縮算法或者壓縮工具

剩下的就是一些擴展的字段了

總結下來，客戶端向服務端第一次打招呼（client Hello）的時候實際上主要發送瞭如下主要的信息

客戶端的隨機數

客戶端所支持的加密套件

以及客戶端和服務器之間的sessionId

接下來就是服務端對客戶端Hello的第一次迴應，也就是編號19372

能夠看到 服務端使用的是443端口，序列號（Sequence number）也是1 ，而且迴應客戶端說我已經確認收到你的202個本身的數據（203-1），Flags代表本次是服務端反饋給客戶端請求的應答（藍色的文字也寫出來了，這是一個隊19371編號的應答）

從圖1能夠看出這是一個TCP鏈接

Server Hello

接下來不等客戶端反應，服務端又給客戶端發送了19373的數據，而這個數據就是使用了TLS1.2協議了。

摘要信息中說明了這是服務端的的hello,Server hello,服務端祕鑰交換，服務端hello done。接下來看服務端發過來的具體都有什麼。

傳輸控制層（transmission control protocol）和上面同樣，主要是一些Flags，端口以及數據長度的確認等等，主要看一下安全套接字層的東西（Secure Sockets Layer）中的東西。

經過上圖，能夠看出服務端主要返回四種內容。

  • Server Hello 服務端的迴應客戶端的hello信息
  • Certificate  服務端證書
  • Server key Exchange 服務器祕鑰交換
  • Server Hello Done 服務器信息發送完畢

詳細看一下各個Record layer中的具體內容

Server Hello

在Server Hello中，服務器返回的服務端的隨機數，所選用的TLS 版本，以及服務器最終選用的客戶端和服務端交互的加密套件（TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)），最終選用的加密套件是RSA非對稱加密算法以及AES對稱加密算法，用的是SHA384作摘要，注意，這個值必須是客戶端發給服務端的列表中選出來的。實際上若是客戶端只能支持版本和安全性比較低的加密套件，這樣服務端選擇和客戶端交互的時候也被迫只能使用低版本的加密套件，其安全性就會下降。除了以上這些，服務端Server Hello時發送回來的還有是否使用了壓縮以及一些其餘的擴展字段

Certificate

Server Hello之後，服務端會發送公鑰證書給客戶端

Certificates (953 bytes)
    Certificate Length: 950
    Certificate: 308203b23082029aa003020102020101300d06092a864886... (id-at-commonName=www.wtf.com,id-at-organizationName=JD,id-at-stateOrProvinceName=BJ,id-at-countryName=CN)
        signedCertificate
            version: v3 (2)
            serialNumber: 1
            signature (sha256WithRSAEncryption)
                Algorithm Id: 1.2.840.113549.1.1.11 (sha256WithRSAEncryption)
            issuer: rdnSequence (0)
                rdnSequence: 7 items (pkcs-9-at-emailAddress=iloveme313@163.com,id-at-commonName=wangtengfei,id-at-organizationalUnitName=section,id-at-organizationName=JD,id-at-localityName=BJ,id-at-stateOrProvinceName=BJ,id-at-countryName=CN)
                    RDNSequence item: 1 item (id-at-countryName=CN)
                    RDNSequence item: 1 item (id-at-stateOrProvinceName=BJ)
                    RDNSequence item: 1 item (id-at-localityName=BJ)
                    RDNSequence item: 1 item (id-at-organizationName=JD)
                    RDNSequence item: 1 item (id-at-organizationalUnitName=section)
                    RDNSequence item: 1 item (id-at-commonName=wangtengfei)
                    RDNSequence item: 1 item (pkcs-9-at-emailAddress=iloveme313@163.com)
            validity
                notBefore: utcTime (0)
                    utcTime: 16-11-22 06:38:18 (UTC)
                notAfter: utcTime (0)
                    utcTime: 17-11-22 06:38:18 (UTC)
            subject: rdnSequence (0)
                rdnSequence: 4 items (id-at-commonName=www.wtf.com,id-at-organizationName=JD,id-at-stateOrProvinceName=BJ,id-at-countryName=CN)
                    RDNSequence item: 1 item (id-at-countryName=CN)
                    RDNSequence item: 1 item (id-at-stateOrProvinceName=BJ)
                    RDNSequence item: 1 item (id-at-organizationName=JD)
                    RDNSequence item: 1 item (id-at-commonName=www.wtf.com)
            subjectPublicKeyInfo
                algorithm (rsaEncryption)
                    Algorithm Id: 1.2.840.113549.1.1.1 (rsaEncryption)
                subjectPublicKey: 3082010a0282010100be56d1a2b725cf5d6fa1997c83b221...
                    modulus: 0x00be56d1a2b725cf5d6fa1997c83b221de8452658b1e7c86...
                    publicExponent: 65537
            extensions: 4 items
        algorithmIdentifier (sha256WithRSAEncryption)
            Algorithm Id: 1.2.840.113549.1.1.11 (sha256WithRSAEncryption)
        Padding: 0
        encrypted: 41bfd96f86c44a731d6ff7af7e9e666703c744aa8c691d38...

1中有證書的指紋，以及證書的簽名信息

Certificate:308203b23082029aa003020102020101300d06092a864886...(id-at-commonName=www.wtf.com,id-at-organizationName=JD,id-at-stateOrProvinceName=BJ,id-at-countryName=CN)

看以看出，這個證書是針對www.wtf.com這個域名簽發的，而後就是一些簽發機構信息等。

2 證書的過時時間（validity），能夠看出證書的過時時間爲1年，從16年11月22日 6點38分18秒(not Before)到從17年11月22日 6點38分18秒(not After)

3 證書籤發的主體(subject)

4 公鑰證書的key.

固然這證書下放之後，服務端會把簽發的證書的hash也發送過來，以證實此證書在傳遞過程當中沒有被修改。

能夠看出使用的sha256算法作的摘要。

證書咱們也能在瀏覽器中用可視化的方法查看。

我會把證書導出，能夠自行查看

接下來就是祕鑰交換了

Server key Exchange

這個就是服務端公鑰的key

HelloDone

最後就是服務端發送一個HelloDone標示本次內容所有發放完畢。

總結一下 在客戶端向服務端打招呼之後，服務端主要發送了那些內容。首先是發送服務端本身的隨機數給客戶端，而後下發服務端公鑰證書和下發公鑰的key，最後服務端用hellodone標示這次內容所有發送完畢。以上發送過程咱們均可以看獲得，也就是說在這個過程當中，客戶端和服務端交互使用的都仍是明文。

Client keyExchange

客戶端接收到服務端的這些證書信息之後，解析來會進行迴應服務端。能夠看19374編號

查看傳輸層，傳輸層中明確寫明瞭這是對19373的一個迴應。

重點仍是查看安全套接字層，具體來看回應的是什麼

 

主要包含了以下幾個方面

Client key exchange

包含了pre-master secret。這是在握手過程當中生成的第三個隨機數。分別是client hello階段客戶端的隨機數，而後在server hello 階段服務端的隨機數。這一次是客戶端接收到服務端的證書之後，生成的一個預加密因子（供對稱加密使用）。

Change cipher spec

客戶端通知服務端接下來就要使用加密的方式來進行通訊了。

而後在19375中，客戶端發送給服務端一段加密後的內容（就是在這一步，數據的交互從明文開始轉化爲密文），而且把本次會話信息中的全部細節作摘要發給服務端，以證實在本次過程當中雙方達成一致，未受到其餘干擾

服務端確認客戶端加密請求

而後服務端會在19376和19377中，服務端對客戶端的發送的內容進行確認（19374），提供新的Session Ticket，而後發送了一段內容，而且對全部握手內容作摘要，發給客戶端來驗證通訊過程是否被篡改。

最後在19378中，客戶端對服務端發送的內容進行作確認

注意一下，這時候內容發送的協議已經不是SSL了，已經從新更改成了TCP

接下來就是在此加密信道上開始正常的業務數據傳輸過程。

（tcp.stream eq 296）

整個交互過程的概要能夠用下圖表示

 

小結：

本文大概的跟蹤瞭如下https創建安全連接的過程，並未提到經常使用的加密算法什麼的用到什麼地方，在本文的最後提一下，https過程的創建，實際上就是一次一密，根本目的是爲了協商出雙方使用哪一種對稱加密算法，而後加密因子是多少，爲了達到這個目的，雙方使用了非對稱加密進行協商，拿到雙方的隨機數，而後進行相關的計算獲得一個隨機對稱加密的加密因子。爲了確保客戶端正在和真正的不是冒牌的服務器在協商，這個就用到了證書，因爲是證書是能夠自簽名的，自簽名是不可信的，因此就須要就須要找一個你們都信任的機構進行簽名，例如CA。這樣瀏覽器纔會承認這個證書。還有就是爲了保證在協商的過程當中不受干擾，在協商的每一步都會把本次會話的信息作摘要傳遞給雙方，用以校驗。

固然了本文只是一個極其粗略的https流程的簡介，https還涉及到不少其餘的內容，例如一些https加密信道的重用，因爲https的創建比較慢，因此google就發明了一種更快的協議QUIC。

因爲做者水平有限，畢竟會有些疏漏以及理解不到位的地方，但願讀者給予指正，以使其餘人不被誤解。

 

附：

https://git.oschina.net/tofu.wang/wireshark-https/tree/master 

從這個裏面能夠下載到本次模擬的證書以及具體用wireshark抓包過來的包，而後打開wireshark進行導入，過濾器寫ip.addr==114.215.88.85 便可

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程