前言
https解密一直是一個難題，市面上的WAf大多數都是類反向代理的，也有部分產品支持透明代理，也就是匿名代理，這里網上教程較多，簡單解釋下：
反向代理：client在訪問server的時候，其實訪問的是代理服務器，代理服務器判斷是否是惡意流量
透明代理：client在訪問server的時候，訪問的是server的真實地址，clinet根本不知道有透明代理服務器
市面上好多開源的WAF都是組件化的，或者是反向代理的，沒有透明代理。我想如何在虛機里面搭一個真實的透明代理，最后決定用兩張網卡解決，一張網卡做入口，另一張網卡做出口，在網卡1處做流量分析，把分析后的正常流量包轉發到網卡2，惡意流量包過濾掉，這樣就可以實現透明代理了，說干就干。
在搭好環境以后，waf已經可以做正常的攔截了，可以這僅僅是攔截http的包，https不能做攔截，反向代理可以解決這個問題，因為client訪問的真實的server端就是代理服務器，但是透明代理的話就需要解決https解包的問題了（咳咳~如果我的理解是對的話）
在網上找了好多教程，結合起來才能解決我遇到的問題，我總結在這里，這里用兩種方式去解包
第一種：SSLKEYLOGFILE解碼
設置環境變量 SSLKEYLOGFILE，將其指向一個可寫入的文本文件。Chrome和Firefox在啟動時會檢查這個環境變量，如果存在的話，它會向指定的文件寫入訪問HTTPS站點時使用的密鑰。在wrieshark首選項-Protocols-TLS中添加txt文件，直接抓包就可以解了。
這里我們可以看到在TLSv1.2的包之后，有已經解包后的HTTP的包
我們可以看到在server端回應的報文里面的加密套件為 TLS_RSA_WITH_AES_128_GCM_SHA256
在temp.txt里面可以看到站點密鑰
第二種：私鑰解碼
最常見的密鑰交換方式是 RSA
Client Random 和 Server Random 明文傳輸，中間人可以直接查看。客戶端生成 Premaster Secret 后，用服務端證書公鑰加密后發送，如果服務端擁有對應的私鑰，就可以成功解密得到 Premaster Secret。這時，客戶端和服務端擁有相同的 Client Random、Server Random 和 Premaster Secret，可以各自算出相同的后續所需 Key。對 Wireshark來說，擁有RSA私鑰就可以解密RSA加密后的網站了。
在wrieshark首選項-Protocols-TLS中添加私鑰，
抓包就可解密，這里我遇到問題，因為我的加密套件里面是有ECDHE的，所以密鑰解密成功，后來找到了問題所在，目前的ECDHE是不可以用私鑰直接解密的，而第一種方法是導入最終的會話密鑰的
Server DH Parameter 是用證書私鑰簽名的，客戶端使用證書公鑰就可以驗證服務端合法性。相比 RSA 密鑰交換，DH 由傳遞 Premaster Scret 變成了傳遞 DH 算法所需的 Parameter，然后雙方各自算出 Premaster Secret。
我使用了RSA的證書和私鑰，然后在火狐瀏覽器中關閉了所有的ECDHE加密套件：在瀏覽器中輸入about:config-接受風險並繼續-搜索DHE-全部關閉之后就可以解包了，如果不能解，重新啟動瀏覽器或對頁面進行強制刷新即可。
問題總結
目前市場上的WAF無非兩類，類似插件的，類反向代理的，但是我有看到有些產品在說透明代理的模式，透明代理的模式在有ECDHE加密的情況下是不可行的，實際上，目前大部分 HTTPS 流量用的都是 ECDHE 密鑰交換。那么想實現透明代理的話，沒有辦法去使用私鑰解密，只能是中間人的方式去解密，這樣的話，還不如直接反向代理，因為client直接訪問的反向代理，那么什QAQ么加密都沒有關系的，在server本身來看，流量就是透明的。目前為止，本人還沒有相通透明代理下如何實現WAF解密HTTPS的問題，又或者只是理論上可行，實際根本就沒有實現，恕我太菜了QAQ
學習參考地址：
https://imququ.com/post/how-to-decrypt-https.html
http://xdxd.love/2018/09/10/利用SSL問題繞過WAF文章分析/