QianHeng乾珩 PQC Docs Hub量子文档 ✦ Ask AI✦ 问问文档 ⚐ Scan⚐ 扫一扫
/

TLS Decryption & PQC

Enterprises inspect TLS traffic at the network edge for threat prevention, data-loss prevention and compliance. Post-quantum key exchange changes that picture: a middlebox that does not understand PQC can no longer decrypt the traffic it is meant to inspect — and the common workaround, stripping PQC to force classical cryptography, directly undermines a PQC migration. This page uses Palo Alto Networks' NGFW decryption as a concrete, well-documented example.

What network decryption is

A next-generation firewall (NGFW) performs decryption to gain visibility into otherwise opaque SSL/TLS and SSH traffic, then re-encrypts it after inspection. It acts as a trusted man-in-the-middle using public/private-key cryptography. The main modes are:

ModeDirectionPurpose
SSL Forward ProxyOutboundInspect traffic from internal clients to the internet (the NGFW presents a re-signed certificate).
SSL Inbound InspectionInboundInspect traffic to internal servers using a copy of the server's key/certificate.
SSH ProxyBothInspect and control SSH tunnels.

Decryption policies select which traffic is decrypted and how; decryption profiles pin the allowed protocol versions and cipher suites. Perfect Forward Secrecy (DHE/ECDHE) is typically enabled by default — which already means the inspector must participate in the key exchange rather than passively decrypt with a static key.

Why PQC collides with inspection

TLS 1.3 hybrid key exchange (for example X25519MLKEM768) negotiates the shared secret with a post-quantum KEM. A decrypting middlebox has to sit inside that key exchange. If it does not implement the PQC KEM, it simply cannot derive the session keys — so it cannot inspect the session at all. This creates two bad outcomes that a security team must choose between:

  • Lose visibility — allow the PQC session through undecrypted (a monitoring/DLP/threat blind spot), or
  • Force a downgrade — make the client fall back to classical-only cryptography so the box can still decrypt — which defeats the purpose of deploying PQC and re-exposes the traffic to "harvest now, decrypt later".

How firewalls detect & control PQC today

Before PQC-aware decryption existed, NGFWs handled PQC by editing the handshake. The firewall inspects the supported_groups extension in the TLS ClientHello and compares the advertised group code points against known PQC and hybrid-PQC algorithms. When a Forward Proxy or Inbound Inspection rule applies:

  • If the client offers both classical and PQC groups, the NGFW removes the PQC and hybrid-PQC groups from the ClientHello, forcing the server to negotiate a classical algorithm it can decrypt.
  • If the client offers only PQC/hybrid groups, the NGFW drops the session and logs Client only supports Post-Quantum algorithms.
  • Under a no-decrypt rule (or no decryption policy at all), the NGFW lets the PQC handshake proceed — gaining privacy but leaving a session it cannot inspect.

Even when it cannot decrypt, this gives security teams traceability: the firewall can detect, log and block PQC/hybrid-PQC usage in TLS 1.3, so an organization can at least measure where PQC is appearing on its network.

Stripping PQC is a deliberate downgrade
Removing PQC groups from the ClientHello forces classical-only key exchange. That keeps the inspector working, but it cancels the quantum-safety benefit for every inspected flow and reintroduces Harvest Now, Decrypt Later (HNDL) exposure. Treat handshake stripping as a temporary bridge, not a destination — and track it as technical debt in your migration plan.

PQC-aware inline decryption

The durable fix is for the inspection device itself to speak PQC. PAN-OS 12.1+ introduces PQC dataplane decryption and inspection, covering SSL Forward Proxy and SSL Inbound Inspection; it also provides PQC Cipher Translation, management-plane TLS PQC, site-to-site VPN and related capabilities. The exact feature boundaries, version numbers and configuration options should be confirmed against Palo Alto Networks' current online documentation. In the decryption profile you can:

  • enable NIST-standardized PQ KEMs (ML-KEM, per FIPS 203) or non-standardized experimental options;
  • enable hybrid post-quantum key exchange — a classical algorithm such as ECDH combined with a PQC KEM (e.g. X25519MLKEM768) so the session is safe against both classical and future quantum attackers while remaining inspectable.

Separately, the firewall's own management-plane TLS has been gaining PQC support, so administrative connections to the device are themselves quantum-safe.

What this means for your migration

  • Inventory your middleboxes. Firewalls, proxies, load balancers and TLS-terminating gateways are exactly the places where PQC rollout breaks — add them to your cryptographic inventory.
  • Sequence inspection with rollout. Upgrade inspection devices to PQC-aware decryption before enabling hybrid PQC on endpoints, or you will be forced into downgrade-stripping.
  • Prefer hybrid. Hybrid key exchange (classical + PQC) is what both browsers and PQC-aware inspectors converge on; it keeps you interoperable during the transition.
  • Watch for silent downgrades. A middlebox that strips PQC can mask the fact that "PQC is enabled" end-to-end — verify the negotiated group on the wire, not just the client config.

Standards & references

Note
Product specifics (PAN-OS versions, profile options) are Palo Alto Networks' and change between releases — confirm against their live documentation. The underlying tension, inspection versus post-quantum confidentiality, applies to every TLS-decrypting middlebox regardless of vendor. See also TLS 1.3 and Hybrid Key Exchange.

TLS 解密与 PQC

企业会在网络边界对 TLS 流量做解密检测，用于威胁防护、数据防泄露与合规。后量子密钥交换改变了这一格局： 不理解 PQC 的中间设备无法再解密它本应检测的流量；而常见的应对手段——剥离 PQC 强制回退经典算法——又会直接破坏 PQC 迁移。 本页以 Palo Alto Networks NGFW 的解密能力为有据可查的具体案例。

什么是网络解密

下一代防火墙（NGFW）通过解密获得对本不可见的 SSL/TLS 与 SSH 流量的可见性，检测后再重新加密。它借助公私钥密码学 充当受信任的中间人。主要模式有：

模式方向用途
SSL Forward Proxy出站检测内网客户端到互联网的流量（NGFW 出示重签名证书）。
SSL Inbound Inspection入站用服务器密钥与证书副本检测进入内网服务器的流量。
SSH Proxy双向检测并管控 SSH 隧道。

解密策略决定哪些流量被解密以及如何处理；解密配置文件限定允许的协议版本与密码套件。 前向保密（DHE/ECDHE）通常默认开启——这本身就意味着检测设备必须参与密钥交换，而不能用静态密钥被动解密。

PQC 为何与检测冲突

TLS 1.3 混合密钥交换（例如 X25519MLKEM768）用后量子 KEM 协商共享密钥。做解密的中间设备必须置身于该密钥交换之中。 若它没有实现该 PQC KEM，就根本推不出会话密钥，也就完全无法检测该会话。安全团队因此被迫在两个糟糕的结果之间二选一：

  • 失去可见性——放行未解密的 PQC 会话（监控/DLP/威胁检测盲区），或
  • 强制降级——让客户端回退到仅经典算法，使设备仍能解密——但这等于放弃了部署 PQC 的意义，并让流量重新暴露于“先收集、后解密（Harvest Now, Decrypt Later, HNDL）”。

当前防火墙如何检测与管控 PQC

在具备 PQC 感知的解密能力之前，NGFW 通过改写握手来处理 PQC。防火墙检查 TLS ClientHello 中的 supported_groups 扩展，将其中通告的组码点与已知 PQC、混合 PQC 算法比对。当命中 Forward Proxy 或 Inbound Inspection 规则时：

  • 若客户端同时提供经典与 PQC 组，NGFW 会从 ClientHello 中删除 PQC 与混合 PQC 组，迫使协商出它能解密的经典算法。
  • 若客户端仅提供 PQC/混合组，NGFW 会丢弃该会话，并记录日志 Client only supports Post-Quantum algorithms。
  • 在不解密规则下（或根本没有解密策略），NGFW 放行 PQC 握手——保住了隐私，却留下一条它无法检测的会话。

即便无法解密，这也为安全团队提供了可追溯性：防火墙能检测、记录并阻断 TLS 1.3 中的 PQC/混合 PQC 使用， 组织至少能掌握 PQC 在自身网络中出现的范围。

剥离 PQC 是一种有意的降级
从 ClientHello 删除 PQC 组会强制经典密钥交换。这能让检测设备继续工作，却抵消了每一条被检测流量的抗量子收益， 并重新引入 HNDL 风险。应把握手剥离当作临时过渡而非终点，并在迁移计划中作为技术债务跟踪。

具备 PQC 感知的内联解密

长久的解法是让检测设备自身会说 PQC。PAN-OS 12.1+ 开始提供 PQC Dataplane 解密与检测能力，覆盖 SSL Forward Proxy 与 SSL Inbound Inspection；同时还提供 PQC Cipher Translation、管理面 TLS PQC、站点到站点 VPN 等能力。具体功能边界、版本号和配置项应以 Palo Alto Networks 当前在线文档为准。在解密配置文件中可以：

  • 启用 NIST 标准化 PQ KEM（ML-KEM，见 FIPS 203）或非标准化的实验性选项；
  • 启用混合后量子密钥交换——把 ECDH 等经典算法与 PQC KEM（如 X25519MLKEM768）组合，使会话既能抵御经典与未来量子攻击，又保持可检测。

此外，防火墙自身的管理面 TLS 也在逐步获得 PQC 支持，使对设备的管理连接本身具备抗量子能力。

对你迁移的意义

  • 盘点中间设备。防火墙、代理、负载均衡、TLS 终结网关正是 PQC 推广最易出问题之处——把它们纳入密码资产清查。
  • 让检测先于推广。在端侧启用混合 PQC 之前先把检测设备升级到 PQC 感知解密，否则只能被迫降级剥离。
  • 优先混合。浏览器与 PQC 感知检测设备都收敛于混合密钥交换（经典 + PQC），它能在过渡期保持互操作。
  • 警惕静默降级。剥离 PQC 的中间设备会掩盖“端到端已启用 PQC”的假象——请核对链路上实际协商的组，而不只是客户端配置。

标准与参考

说明
产品细节（PAN-OS 版本、配置项）属于 Palo Alto Networks 且会随版本变化——请以其在线文档为准。但其底层矛盾， 即“检测”与“后量子机密性”之间的张力，适用于任何做 TLS 解密的中间设备，与厂商无关。另见 TLS 1.3 与 混合密钥交换。
⚑ Report an error⚑ 纠错与校正