概述
針對早期的安全裝置來說，若用戶端與伺服器之間使用的是https，那麼任何資料都已經變為加密資料了，如果沒有進行特殊處理，對封包内容進行解密，那麼無論是防火牆上的任何相關的安全内容的功能可能都不會去生效，比如反病毒，針對華為的防火牆來說，他的反病毒主要是依靠識别支援的協定，并從流量中提取特征在病毒庫中進行特征比對之後才會進行相關的安全内容的檢查，二對于華為防火牆内置的IPS來說，幾乎也是大同小異也是靠收集來的巨大的簽名特征庫去對相關的流量進行審查。但是若資料被SSL層加密了，那麼就可以說是無計可施了。是以SSL的流量解密時必不可少的，但是同樣的若在同一時間上有多個使用者建立https的會話，那麼毫無疑問将會導緻防火牆性能的下降。而且在一個區域網路的内部一台主機或者終端可能會存在5-10個https的會話，那麼可能一台防火牆要承載的會話的數目将會到達上千個，是以在這種情況下，他的解密工作也就是顯得十分的龐大，那麼對于一台防火牆來說，尤其是NGFW，它是否可以在兼顧多種安全功能的同時還滿足最基本的安全過濾。我感覺可能有點懸。是以針對某些重要主機，或者重要網站的通路的時候，開啟這個流量解密是比較合适的，否則将引起性能下降。
基本原理
上圖是防火牆在選擇是否進行SSL流量解密的整個流程，可以看見其實本質還是先進行安全政策的比對，然後再判斷是否對其進行解析，解析後如果沒有比對上相關的安全内容，那麼将會被防火牆丢棄。
出站方式的保護
上圖參考的應該是TLS1.1或者TLS1.2，在TLS1.3版本相關對稱密鑰的生成已經可以做到1RTT，但是其實相關内容的協商也是大同小異，主要就是用戶端向伺服器發送TLS的協商請求，然後FW代替用戶端向伺服器發送協商請求，然後伺服器會與防火牆建立相關的TLS連接配接，在這個過程中FW會使用CA憑證去驗證伺服器的證書是否合法，主要的驗證手段就是使用合法的CA憑證的公鑰去對它發來的數字證書中的哈希值進行解密，然後再用數字證書中已知的内容進行相同的哈希計算，最後通過比對來證明該數字證書的真實性。當數字證書驗證通過後，FW會與伺服器建立一個SSL的連接配接，随後FW使用SSL解密證書去簽發一個溝通證書（SSL解密證書需要防火牆導入或者自己生成，如果是自己生成其實就有點像自簽名證書，這個就相當于是CA伺服器的證書，将這個證書需要将其導入到用戶端的電腦上并信任），溝通證書就有點像伺服器去像CA機構申請的證書，FW生成了溝通證書之後會将這個證書發送給用戶端進行後續的SSL連接配接的建立，因為在用戶端上已經安裝了相關的SSL解密證書，而溝通證書正是SSL解密證書簽發的，是以當用戶端已經将那個SSL解密證書表示對它的信任的時候并将其作為一種信任的CA憑證導入的時候，用戶端使用這個SSL解密證書去對溝通證書進行驗證的時候是一定可以驗證通過的，若沒有導入的話，你的浏覽器将會顯示出不信任的證書的相關字眼。于是FW和用戶端也會建立相關的SSL連接配接，同樣的也會生成用于相關資料通信的密鑰。
是以當用戶端向FW發送加密資料的時候，防火牆會将其進行解密判斷目的URL或者是否正确對其進行安全保護。SSL流量解密分為出站方向和入站方向。這個方向的限制并不是指明進行流量解析的方向，而是表示不同的保護方式，上面例子就是出站。當SSL流量進後不僅要通過安全政策的檢查，而且還要通過SSL解密政策的檢查後才會進行SSL的流量解密。
入站方式的保護
如圖所示，内網有一台伺服器要向外提供服務，為了保護内部網絡的伺服器，在防火牆上開啟SSL的流量解密。其實和第一種出站的保護方式類似，第一種出站的保護方式是FW僞裝自己是外部的伺服器并與主機進行SSL連接配接，而入站的保護方式是FW僞裝自己是内部的伺服器，并向外網主機進行SSL的連接配接。其實核心思想還是沒有改變，隻不過是用戶端方向的改變。但是還是有些小細節發生了改變，因為在這個例子當中防火牆要僞裝内部網絡的伺服器，是以它要導入内部伺服器的證書以及證書對應的私鑰。這樣才能給與外網用戶端正常的回應。FW與内部伺服器之間不需要其他額外的内容進行導入，因為FW相對于内部伺服器來說僅僅做的是SSL協商的請求以及後續的相關協商封包的互動并最終建立SSL連接配接。内部的伺服器是被驗證的角色，而FW是驗證者的角色。