http/https鏡像流量的解析問題

場景

由于業務需要，客戶提供http/https的流量鏡像，讓我們分析是否有異常行為。由于我們的系統的輸入源隻能是日志，故最快捷的辦法是把http/https流量轉換成http日志已滿足異常分析的需求。

流量鏡像或者複制方式

端口鏡像

通過交換機或路由器上的端口鏡像功能，将一個或多個源端口的資料流量轉發到某一個指定端口來實作對網絡的監聽，指定端口稱之為“鏡像端口”或“目的端口”，在不嚴重影響源端口正常吞吐流量的情況下，可以通過鏡像端口對網絡的流量進行監控分析。由于要擷取http/https的request和response資料，故要做雙向鏡像。

優點：

1、成本低廉，不需要增加任何網絡裝置；

2、啟動端口鏡像會話(Session)時，對交換機的性能基本無影響；

3、可從交換機上采集到所有使用者通路請求資料；

4、故障保護，當采集系統或前置機出現故障時，對現有的網絡和業務沒有任何影響。

缺點：

1、占用交換機端口：采集系統需要和交換機直連，将占用交換機一定數量的GE和FE端口；

2、需要修改交換機配置：需要修改交換機的配置，将合适的流量複制到鏡像端口，但在修改配置時不會對交換機性能和業務有影響；

分光器

對于某些節點，寬帶接入伺服器通過光口GE鍊路直接與核心路由器（一般為Cisco GSR）相連，寬帶接入伺服器及GSR均不支援端口鏡像，這時采用分光器進行流量采集是最合适的方法。當某些節點的核心交換機、彙聚層交換機沒有足夠的GE端口，不适合采用端口鏡像進行流量采集時，或希望在出口采集網絡流量，就可以采分光器進行流量采集。分光器是一種無源光器件，通過在實體層上進行光複制來進行使用者通路請求資料的采集，其優缺點如下。

1、性能優異：可支援GE甚至在2.5Gbps POS鍊路上通過分光器進行流量采集；

2、故障保護：當采集系統故障時，對現有網絡及業務無任何影響；

3、無需修改現有網絡裝置的任何配置，不改變網絡結構，可采集到所有的網絡流量，和網絡無縫內建；

4、可靠性高：分光器是一種無源光器件，可以看作是一種特制的光纖，可靠性高；

5、不占用網絡裝置端口，投入成本低。

需要将裝置的上聯光纖改為分光器，這涉及到一次簡單的網絡割接，這将導緻網絡瞬時中斷（不超過5秒鐘），對業務有細微的影響；

iptables TEE子產品

使用iptables即可實作把web伺服器上的流量鏡像到同一個網段的其它機器做分析

1，純軟體，使用友善

2，對現有網絡及業務無任何影響

3，保留的原資料包的大部分原始資訊

1，會改變包的源mac和目的mac位址

2，必須同一個網段才能做流量鏡像

流量複制相關軟體工具

使用tcpcopy，gor工具，隻能用于http協定的流量copy，需要真實業務的後端才能擷取的response資料，并且需要在客戶的web server上安裝agent，一般用于測試環境的引流測試。

http流量鏡像轉化為日志

通過交換機的端口鏡像把進入web伺服器的流量給鏡像到分析伺服器的一個空閑網口。使用bro工具，監聽流量鏡像過來的分析伺服器的網口，預設會自動抓取http流量，并且記錄http相關資料到預設的http log檔案，且日志格式中包含了http request和response的大部分資料。但是，此工具不支援https。

官方位址如下：

https://www.bro.org/

https://github.com/bro/bro

https流量鏡像轉化為日志

研究了Bro，snort，wireshark等網絡監控工具，得出如下結論：

1，像Bro，snort這種IDS工具都不支援https

2，wireshark(指令行有tshark工具)可以通過導入https server端私鑰，來解密密鑰交換算法是RSA的流量，進而解密https流量。

官方文檔：https://wiki.wireshark.org/SSL

既然，wireshark能滿足部分的需求，故我們繼續跟蹤了解一下。密鑰交換算法是CipherSuite裡面的東西，故我們先了解一下CipherSuite。

加密套件

加密套件（CipherSuite），是在 SSL 握手中需要協商的很重要的一個參數。用戶端會在 Client Hello 中帶上它所支援的 CipherSuite 清單，服務端會從中標明一個并通過 Server Hello 傳回。如果用戶端支援的 CipherSuite 清單與服務端配置的 CipherSuite 清單沒有交集，會導緻無法完成協商，握手失敗。

CipherSuite 包含多種技術，例如認證算法（Authentication）、加密算法（Encryption）、消息認證碼算法（Message Authentication Code，簡稱為 MAC）、密鑰交換算法（Key Exchange）和密鑰衍生算法（Key Derivation Function）。

SSL 的 CipherSuite 協商機制具有良好的擴充性，每個 CipherSuite 都需要在 IANA 注冊，并被配置設定兩個位元組的标志。全部 CipherSuite 可以在 IANA 的 TLS Cipher Suite Registry 頁面檢視。

OpenSSL 庫支援的全部 CipherSuite 可以通過以下指令檢視：

# openssl ciphers -V
0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD           

1，0xC0,0x30是CipherSuite的編号，在SSL握手中會用到

2，ECDHE-RSA-AES256-GCM-SHA384是加密套件的名稱

3，TLSv1.2辨別用于TLSv1.2協定。TLS（Transport Layer Security，傳輸層安全）的前身是 SSL（Secure Sockets Layer，安全套接字層），它最初的幾個版本（SSL 1.0、SSL 2.0、SSL 3.0）由網景公司開發，從 3.1 開始被 IETF 标準化并改名，發展至今已經有 TLS 1.0、TLS 1.1、TLS 1.2 三個版本。SSL 1.0 從未公開過，而 SSL 2.0 和 SSL 3.0 都存在安全問題，不推薦使用。Nginx 從 1.9.1 開始預設隻支援 TLS 的三個版本

4，Kx=ECDH辨別使用ECDH做密鑰交換

5，Au=RSA辨別使用RSA做認證

6，Enc=AESGCM(256)辨別使用AESGCM(256)做對稱加密

7，Mac=AEAD辨別ChaCha20-Poly1305是一種AEAD模式，不需要MAC算法

以nginx和firefox為例，來看看server端和client端支援的加密套件

1，檢視配置nginx伺服器端加密套件的指令如下：

Syntax: ssl_ciphers ciphers;
Default:    
ssl_ciphers HIGH:!aNULL:!MD5;
Context:    http, server

Specifies the enabled ciphers. The ciphers are specified in the format understood by the OpenSSL library, for example:
      ssl_ciphers ALL:!aNULL:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;

The full list can be viewed using the “openssl ciphers” command.The previous versions of nginx used different ciphers by default.           

關于ssl_ciphers中的關鍵字HIGH,MEDIUM,LOW等配置，可以通過如下指令擷取詳情：

# openssl ciphers -V 'HIGH:!aNULL:!MD5'
# man ciphers //可以擷取具體HIGH,MEDIUM,LOW等的具體解釋           

2，對應https的client端，也會有對應支援的加密套件，像curl，浏覽器等都會有相關的标準。如下為firefox支援的加密套件：

https://wiki.mozilla.org/Security/Server_Side_TLS

了解了加密套件，我們就能知道哪些CipherSuite是使用了RSA密鑰交換算法的。而下一個問題是為什麼拿到server端的https證書之後，隻有RSA密鑰交換算法的CipherSuite能破解。像主流的DH/ECDH密鑰交換算法不能破解呢？下面我們來看看他們的差別。

RSA和DH密鑰交換算法的差別

密鑰交換算法的作用：（在身份認證的前提下）規避【偷窺】的風險。通俗地說，即使有×××者在偷窺你與伺服器的網絡傳輸，用戶端（client）依然可以利用“密鑰協商機制”與伺服器端（server）協商出一個用來加密應用層資料的密鑰（也稱“會話密鑰”）。

1，RSA密鑰交換算法

RSA 是一種【非】對稱加密算法。在本系列第1篇的背景知識介紹中，已經聊過這種算法的特點——加密和解密用使用【不同的】密鑰。并且“非對稱加密算法”既可以用來做“加密/解密”，還可以用來做“數字簽名”。

握手過程：

密鑰協商的大概步驟：

1. 用戶端發送client hello，client随機數以及用戶端支援的加密套件等資訊到服務端
2. 服務端發送server hello，發送服務端端随機數和CA憑證等資訊給用戶端
3. 用戶端驗證該證書的可靠性，并從 CA 證書中取出公鑰。用戶端生成一個随機密鑰 Premaster Secret k，并用這個公鑰加密得到 k'，用戶端把 k' 發送給服務端
4. 服務端收到 k' 後用自己的私鑰解密得到Premaster Secret k
5. 這時，用戶端和服務端擁有相同的 client随機數、server随機數和 Premaster Secret，可以各自算出相同的後續所需的用于對稱加密的session key。這個session key用于後期傳輸資料的加密和解密。           

如何防範偷窺（嗅探）

×××方式1:×××者雖然可以監視網絡流量并拿到公鑰，但是【無法】通過公鑰推算出私鑰（這點由 RSA 算法保證）

×××方式2:×××者雖然可以監視網絡流量并拿到 k'，但是×××者沒有私鑰，【無法解密】 k'，是以也就無法得到Premaster Secret k           

如何防範篡改（假冒身份）

×××方式1:如果×××者在第2步篡改資料，僞造了證書，那麼用戶端在第3步會發現（這點由證書體系保證）

×××方式2:如果×××者在第6步篡改資料，僞造了k'，那麼服務端收到假的k'之後，解密會失敗（這點由 RSA 算法保證），服務端就知道被×××了。           

根據以上的原理，我們知道隻要我們拿到服務端的private key，就可以解密得到client随機數、server随機數和 Premaster Secret，故就可以計算得到session key，故也可以解密傳輸的資料了。

2，DH密鑰交換算法

DH 算法又稱“Diffie–Hellman算法”。這是兩位數學牛人的名稱，他們創立了這個算法。該算法用來實作【安全的】“密鑰交換”。它可以做到——“通訊雙方在完全沒有對方任何預先資訊的條件下通過不安全信道建立起一個密鑰”。這句話比較繞口，通俗地說，可以歸結為兩個優點：

1. 通訊雙方事先【不】需要有共享的秘密。
2. 用該算法協商密碼，即使協商過程中被别人全程偷窺（比如“網絡嗅探”），偷窺者也【無法】知道協商得出的密鑰是啥。

但是，DH 算法本身也有缺點——它不支援認證。也就是說：它雖然可以對抗“偷窺”，卻無法對抗“篡改”，自然也就無法對抗“中間人×××/MITM”。為了避免遭遇MITM×××，DH需要與其它簽名算法（比如RSA、DSA、ECDSA）配合——靠簽名算法幫忙來進行身份認證。當DH與RSA配合使用，稱之為“DH-RSA”，與DSA配合則稱為“DH-DSA”等。

DH的算法模型：

DH利用了數學上的一個“不可逆”的運算，就是離散對數。最終兩個人得到的秘密數字都是g^(ab) mod p，而竊聽者僅從p,g,A,B四個公開資訊，是無法得到這個秘密數字的！

舉個例子，假如p=23,g=5,Alice選取的秘密數字a=6,那麼A=5^6 mod 23 =8，Bob選取的秘密數字是15，那麼B=5^15 mod 23 = 19, 交換A和B後，Alice計算出的密鑰S=19^6 mod 23=2,Bob計算出的密鑰S=8^15 mod 23=2

當然，實際運算中不可能取這麼小的數值，比如如果需要128bit長度的密鑰，那麼p值需要是128bit長度的質數，由于有模運算，所獲得的密鑰不會大于p，是以p值可以是128bit數字中最大的一個質數，g可以随便設定一個小的質數即可。

1. 用戶端發送client hello，client随機數以及用戶端支援的加密套件等資訊到服務端
2. a：服務端發送server hello，發送服務端端随機數和CA憑證等資訊給用戶端。
   b: 服務端利用私鑰将用戶端随機數，服務端随機數，服務端DH參數簽名，生成服務端的簽名。
3. 服務端向用戶端發送服務端DH參數以及伺服器簽名(Server Key Exchange)
4. 用戶端驗證簽名的有效性，然後向服務端發送用戶端DH參數(Client Key Exchange)。
5. 用戶端與服務端各自利用服務端DH參數、用戶端DH參數生成預主密鑰Premaster Secret。然後，用戶端和服務端各自再通過預主密鑰、用戶端随機數、服務端随機數生成session key。這個session key用于後期傳輸資料的加密和解密。           

通過以上對RSA和DH密鑰交換算法的了解，我們知道Premaster Secret是通過用戶端和服務端根據某些算法算出來而通過傳輸的資料不能算出來Premaster Secret，并且Premaster Secret不會再用戶端和伺服器端進行傳輸，是以是安全的，即使拿到了私鑰也解密不了DH密鑰交換算法的流量。

wireshark用私鑰解析密鑰交換算法為RSA的流量

wireshark的指令行工具tshark用私鑰解析密鑰交換算法為RSA的流量

# tshark -o "ssl.desegment_ssl_records: TRUE" -o "ssl.desegment_ssl_application_data: TRUE" -o "ssl.keys_list: 1.1.1.2,443,http,/usr/local/openresty/nginx/conf/STAR.key" -o "ssl.debug_file: /root/wireshark-log" -i em1 -R "tcp.port == 443"
tshark: -R without -2 is deprecated. For single-pass filtering use -Y.
Running as user "root" and group "root". This could be dangerous.
Capturing on 'em1'
482 5.919169492 1.1.1.1 -> 1.1.1.2 TCP 78 58299 > https [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=1069340243 TSecr=0 SACK_PERM=1
483 5.919225218 1.1.1.2 -> 1.1.1.1 TCP 74 https > 58299 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=2066693868 TSecr=1069340243 WS=128
484 5.923009324 1.1.1.1 -> 1.1.1.2 TCP 66 58299 > https [ACK] Seq=1 Ack=1 Win=131712 Len=0 TSval=1069340247 TSecr=2066693868
485 5.928874631 1.1.1.1 -> 1.1.1.2 SSL 302 Client Hello
486 5.928911090 1.1.1.2 -> 1.1.1.1 TCP 66 https > 58299 [ACK] Seq=1 Ack=237 Win=30080 Len=0 TSval=2066693878 TSecr=1069340251
487 5.929678631 1.1.1.2 -> 1.1.1.1 TLSv1.2 4727 Server Hello, Certificate, Server Hello Done
488 5.933984079 1.1.1.1 -> 1.1.1.2 TCP 66 58299 > https [ACK] Seq=237 Ack=2897 Win=128832 Len=0 TSval=1069340256 TSecr=2066693879
489 5.934407243 1.1.1.1 -> 1.1.1.2 TCP 66 58299 > https [ACK] Seq=237 Ack=4662 Win=127104 Len=0 TSval=1069340256 TSecr=2066693879
490 5.934426509 1.1.1.1 -> 1.1.1.2 TCP 66 [TCP Window Update] 58299 > https [ACK] Seq=237 Ack=4662 Win=131008 Len=0 TSval=1069340256 TSecr=2066693879
491 5.950389947 1.1.1.1 -> 1.1.1.2 TLSv1.2 424 Client Key Exchange, Change Cipher Spec, Finished
493 5.958089813 1.1.1.2 -> 1.1.1.1 TLSv1.2 157 Change Cipher Spec, Finished
494 5.961313957 1.1.1.1 -> 1.1.1.2 TCP 66 58299 > https [ACK] Seq=595 Ack=4753 Win=130944 Len=0 TSval=1069340282 TSecr=2066693907
495 5.962071856 1.1.1.1 -> 1.1.1.2 HTTP 215 GET / HTTP/1.1
496 5.962380525 1.1.1.2 -> 1.1.1.1 HTTP 935 HTTP/1.1 200 OK  (text/html)
497 5.966018287 1.1.1.1 -> 1.1.1.2 TCP 66 58299 > https [ACK] Seq=744 Ack=5622 Win=130176 Len=0 TSval=1069340286 TSecr=2066693911
498 5.966451735 1.1.1.1 -> 1.1.1.2 TLSv1.2 135 Alert (Level: Warning, Description: Close Notify)
499 5.966560747 1.1.1.2 -> 1.1.1.1 TCP 66 https > 58299 [FIN, ACK] Seq=5622 Ack=813 Win=32256 Len=0 TSval=2066693916 TSecr=1069340286
500 5.967596840 1.1.1.1 -> 1.1.1.2 TCP 66 58299 > https [FIN, ACK] Seq=813 Ack=5622 Win=131072 Len=0 TSval=1069340287 TSecr=2066693911
501 5.967625107 1.1.1.2 -> 1.1.1.1 TCP 66 https > 58299 [ACK] Seq=5623 Ack=814 Win=32256 Len=0 TSval=2066693917 TSecr=1069340287
502 5.970093517 1.1.1.1 -> 1.1.1.2 TCP 66 [TCP Out-Of-Order] 58299 > https [FIN, ACK] Seq=813 Ack=5623 Win=131072 Len=0 TSval=1069340289 TSecr=2066693916