FortiGate 加密流量检测实战：SSL/TLS 深检的三种模式、豁免设计与性能账

一、先说清楚：现在到底看不见什么

按 Google 透明度报告的口径，目前约 95% 的 Web 流量跑在 HTTPS 上。Zscaler ThreatLabz 2026 年的钓鱼与初始访问报告更直白：95.2% 的钓鱼尝试藏在加密流量里，87% 的恶意活动通过 HTTPS 投递。

这组数字的意义不在"加密普及了"，而在另一件事：如果你的出口防火墙没做解密，IPS、AV、Web 过滤、DLP 这些引擎实际上在对一堆密文做判断。它们能看到 SNI、服务器证书、TLS 记录的大小和时序，然后就没了。恶意载荷、C2 心跳、外发数据，全在隧道里面。

换个说法：加密把"内容检测"变成了"元数据分析"。这不是危言耸听，是很多单位买了 NGFW 却觉得"好像没拦到什么"的原因之一。

二、三种模式：别一上来就开深检

FortiOS 内置的 SSL/SSH 检测配置里有三种常用模式，理解它们的差异比记住命令重要。

模式	是否解密	能看到什么	性能影响	适用场景
no-inspection	否，端到端直通	连接层信息：源/目的 IP、端口、会话	几乎无	明确可信或受合规约束、不允许解密的流量
certificate-inspection	否，只看握手	服务器证书、证书链、有效期、签发者、SNI	较小	通用出口流量的基线检测， Abnormal 证书拦截
deep-inspection	是，中间人解密后重签	完整明文，AV / IPS / Web 过滤 / DLP 全部生效	明显，取决于硬件卸载能力	高风险类别、下载行为、未知站点、外发数据管控

我见过不少团队的做法是：既然深检看得见，那就全开。第二天早上工单系统爆了：网银打不开、企业微信连不上、某个业务 App 卡在登录页转圈。然后紧急回滚，从此 SSL 检测被打上"这功能不稳定"的标签，一挂就是两年。

问题不在功能，在于深检从来不是个开关，它是一份需要提前签的责任书。

三、深检到底做了什么

把流程拆开看，就明白为什么它需要那么多前置条件。

1. 客户端向服务器发起 TLS 握手。
2. FortiGate 拦截这次握手，用自己 CA 签发的证书充当服务器，回应客户端。
3. FortiGate 同时向真实服务器发起另一条 TLS 连接，验证真证书，取回响应内容。
4. 再用自己的证书把内容重新加密，回传给客户端。

第 3 步和第 4 步之间那段明文，才是 AV、IPS、Web 过滤、DLP、文件过滤能干活的地方。

这里有个绕不开的前提：客户端必须信任 FortiGate 的 CA。否则浏览器满屏证书告警，用户第一反应是"网络坏了"。实务上有两种做法，用设备自签证书，或者由企业 CA 签发一张 subordinate 证书给 FortiGate。后者更可控，也更容易通过内部安全审计。终端侧通过域控组策略下发根证书，这一步的工作量要提前算进项目计划，不能等到上线当天才想起来。

四、豁免清单：这一步决定项目成败

真正决定 SSL 检测能不能平稳落地的，不是配置本身，是豁免清单。有三类流量必须提前识别出来。

证书固定（certificate pinning）

部分 App 在代码里写死了服务端证书或公钥指纹。一旦看到被重签的证书，它不弹窗、不提示，直接拒绝连接。典型场景包括金融类 App、应用商店、Apple 推送服务、部分 SaaS 客户端。这类流量你解不了，只能放行。

双向 TLS（mTLS）

服务端要求客户端出示证书时，FortiGate 在深检过程中不会把客户端证书中继给服务器。结果就是握手失败，业务中断。这类流量要么整段绕过，要么干脆不纳入深检范围。

合规与隐私约束

金融、医疗、涉及个人敏感信息的流向，很多单位按内部规定就不允许解密，哪怕技术上做得到。FortiGate 支持按 FortiGuard 分类（例如金融、健康类目）或按地址对象组整段豁免，把合规要求落成配置。

豁免的写法大致是这样：

config firewall ssl-ssh-profile
  edit "custom-deep-inspection"
    config ssl-exempt
      edit 1
        set type fortiguard-category
        set fortiguard-category 31        # 金融类目
      next
      edit 2
        set type address
        set address "exempt-pinned-apps"  # 证书固定的业务域名组
      next
    end
  next
end

更有用的做法是先别急着列清单：先整网跑两周 certificate-inspection，看日志里哪些类别和域名占比高、哪些告警多、哪些握手反复失败。用真实流量把豁免清单"跑"出来，比坐在会议室里拍脑袋靠谱得多。

五、性能账：三个数字要对着看

这一段是选型时容易吃亏的地方。厂商规格表上的吞吐通常分三档写：防火墙吞吐、威胁防护吞吐、SSL 检测吞吐。只盯着第一档买设备，上线一开深检就发现扛不住。

举个具体例子：FortiGate 1800F 标称威胁防护吞吐约 11 Gbps，SSL 检测吞吐约 7.4 Gbps。中间那 3 Gbps 多的差额，就是解密和重加密的代价，不是厂商虚标，是物理规律。

卸载：把密码学运算挪出 CPU

中高端机型带专用安全处理器（CP9 / SP5 这类），专门处理 TLS 加解密，不用占主机 CPU。确认是否启用：

config system global
  set ssl-hw-acceleration enable
end

灰度期间该盯哪些指标

开深检不是一次性的，得边开边看。这几个命令建议放进日常巡检：

• diagnose sys cps stats：看安全处理器利用率
• get system performance status：主机 CPU 与内存
• diagnose sys session stat：会话数是否接近上限
• diagnose firewall ssl-cert-cache list：证书缓存状态
• diagnose ips ssl conn：当前被解密的连接

有个经验值得记：在 HTTPS 占比高的环境里，往往是先撞到安全处理器的天花板，而不是网络处理器的吞吐上限。也就是说配 SSL profile 的时候，心里要有个数：这台机型的解密并发能力大概到哪，剩下的流量留给证书检测和行为分析。

六、TLS 1.3 与 ECH：2026 年新增的麻烦

这一段是今年和前两年不一样的地方。TLS 1.3 已经收窄了不少明文元数据，而 ECH（Encrypted Client Hello）走得更远：连 SNI 和证书信息都一并加密。

直接的后果是，certificate-inspection 这种"只看握手"的模式，能拿到的信息会越来越少。以前还能靠证书签发者、有效期判断异常，ECH 普及之后这部分也黑了。

所以现实的做法不是"全解"，也不是"干脆不解"，而是分层：

• 能解且风险高的：深检，交给 AV / IPS / DLP。
• 解不了的：退到握手指纹和行为分析。JA3 / JA4 这类指纹对 C2 框架识别仍然有效，配合 Beacon 周期、流量时序、非常规目的地的观测，能补上一部分视野。
• 明确豁免的：放行，但记录完整日志，出事时可回溯。

把希望全押在"解开一切"上，在 2026 年已经不现实了。分层检测不是退而求其次，是更贴近现实的方案。

七、落地顺序：一条能照着走的路径

1. 先摸清出口流量构成：类别分布、占比、哪些属于业务关键。这一步省不掉。
2. 整网上 certificate-inspection，跑两周，收集日志与失败握手。
3. 用日志定豁免清单：证书固定、mTLS、合规三类分别建组。
4. 按类别灰度开深检：先从非业务关键的通用 Web 开始，稳定一批再扩一批。
5. 设性能阈值告警：安全处理器利用率、CPU、会话数各设一条线。
6. 纳入日常巡检，别只在出事时才去看 SSL 检测状态。

整个过程两三周不算长，跳过任何一步，后面多半要补回来。

八、常见误区

九、常见问题（FAQ）

十、小结

加密流量检测这件事，技术门槛其实不高，难在工程纪律：先摸清流量、用日志定豁免、按类别灰度、把性能阈值设上、让清单能持续维护。做到这几点，深检不会变成半夜的故障来源。

放到整体架构里看，SSL 检测只是 FortiGate 能力的一块拼图。配合 下一代防火墙的融合进化、Hybrid Mesh Firewall 架构思路 与 Secure SD-WAN 多分支实践，企业可以把"看得见"这件事从单点设备扩展到整张网络。具体型号能力、固件版本支持与安全处理器规格，建议以官方兼容性矩阵和实际评估为准，也可参考 Fortinet FortiGate 产品 做选型对照。