場景
由於業務需要，客戶提供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=AEAD1，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.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算法”。這是兩位數學牛人的名稱，他們創立了這個算法。該算法用來實現【安全的】“密鑰交換”。它可以做到——“通訊雙方在完全沒有對方任何預先信息的條件下通過不安全信道創建起一個密鑰”。這句話比較繞口，通俗地說，可以歸結爲兩個優點：
- 通訊雙方事先【不】需要有共享的祕密。
- 用該算法協商密碼，即使協商過程中被別人全程偷窺（比如“網絡嗅探”），偷窺者也【無法】知道協商得出的密鑰是啥。
但是，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的流量
1，wireshark版本爲2.4.2
2，打開已經準備好的pcap文件，我們可以看到數據是加密的
3，選擇wireshark中的perferences>Protocols->ssl
4，配置ssl相關設置
ip address：ssl服務端的ip地址
port：ssl服務端的端口
protocol：加密協議被解密之後所使用的協議。如果是https的話，解密之後是http協議
key file：私鑰的路徑
password： 私鑰是pem格式的話，一般設置爲空即可
5，查看解密之後的流量