概述
针对早期的安全设备来说，若客户端与服务器之间使用的是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是验证者的角色。