23、HTTPS加密流量解析技术分析

HTTPS 加密流量解析技术分析：对称与非对称混合加密原理、TLS 握手与密钥协商流程、持有证书私钥仍无法解析旁路镜像流量的原因（DH/ECDHE 前向保密）、可实现旁路解密的四类情形与适用边界、确需内容级审计的可行路径，以及现场确认实际协商密钥交换算法的核查命令与版本适用性对照。
Categories:

  3 分钟阅读  

定位：HTTPS 加密流量的解密原理与旁路审计设备的适用边界，供测评师判断「流量类检测设备是否真的具备检测能力」。 测评关联：数据完整性/保密性 a)（传输加密有效性核查）、安全区域边界-入侵防范（NTA/IDS/IPS 对加密流量的可见性）、 27、绿盟网络入侵检测系统（NIDS）、08、绿盟堡垒机测评。 适用：TLS 1.0~1.3；TLS 1.3 已移除 RSA 密钥交换，仅保留 (EC)DHE，本文结论在 TLS 1.3 下更趋绝对。

加密技术是最常用的安全保密手段，能够保护数据不被窥视，但是也产生了新的问题，一方面是应用系统业务流量加密后，企业自身基于流量内容分析的旁路安全设备将失效，另一方面，攻击者会借助加密流量实施恶意攻击，避开各类NTA产品的检测。

针对加密流量，目前主流的攻击分析手段包括解密后分析和不解密分析。现在网上大多数的文章都是针对“不解密条件下识别和阻断恶意流量”进行分析，在和客户沟通过程中，发现大家其实一直对“如何进行业务加密流量解密分析”存在疑问，只知道针对现有HTTPS的业务，将加密流量通过镜像的方式转发给安全设备探针，安全设备即使导入了证书和服务端私钥也没法解析出内容，却不知道为什么。另外，众多安全厂商宣称其Tap镜像网、数据防泄漏、邮件审计、流量分析产品有旁路解密方案，又是如何做到的？我们慢慢往下看。

本文主要针对HTTPS业务，解析安全设备对其流量进行解密的条件和原理，未尽之处，欢迎大家探讨指正。

使用说明：

  • 本文所有命令均为只读取证命令，不修改配置、不重启服务、不执行清除类操作；确需变更由被测单位运维方在授权下实施。
  • 命令回显本身即证据，须连同命令行一起截图；示例中的地址、账户、路径均为演示值，现场须替换为真实取证结果，并对个人信息与内网管理地址脱敏后再入报告。
  • 命令不存在或输出与示例差异较大时，先确认产品版本与部署形态（物理机/虚拟机/容器/集群），再换用等效命令或转入配置文件、管理控制台取证，不得据命令缺失直接判不符合。
  • 文中「默认」「一般」等表述均为初判倾向，须经上机核查 + 访谈 + 配置/制度核对三方印证后定论，并在报告中写明取证来源。

不适用标识说明：

  • 使用 【不适用】 明确标记现场可判定为不适用的控制点，并写明判定依据与承载该能力的上位组件。
  • 依据 GB/T 28448-2019「按测评对象实际承载功能与数据处理范围判定」原则：控制能力由上层应用、统一认证平台、前置代理、堡垒机、日志审计系统、虚拟化平台或云托管平台承载时，应注明测评单元边界后判定不适用或转由上位组件核查，不得机械按缺失判不符合。
  • 产品版本确实不提供该能力（如设备无可信根、社区版无审计模块）时，须核查替代措施并按替代措施的实际效果定档，不得直接判不适用。

一、HTTPS 加解密原理

HTTPS 与 TLS 在协议栈中的位置

要知道HTTPS业务的流量加解密原理，首先要知道HTTPS业务的加解密方式和流程。如下图，HTTPS在HTTP的基础上，通过传输加密和身份认证来保证传输过程的安全性，利用TLS和SSL对通信协议进行加密。

1.1 为什么 HTTPS 要用对称 + 非对称加密？

我们首先来复习一下对称加密、非对称加密和散列函数

对称加密指的是加密和解密使用同一个秘钥，对称加密只有一个秘钥。优点：计算量小、加密速度快、加密效率高，缺点：秘钥的管理和分发非常困难，不够安全。

非对称加密指的是加密和解密使用不同的秘钥，一把作为公开的公钥，另一把作为私钥，公钥加密的信息，只有私钥才能解密，私钥加密的信息，只有公钥才能解密，私钥只能由一方安全保管，不能外泄，而公钥则可以发给任何请求它的人。优点：安全性更高，公钥是公开的，秘钥是自己保存的，密匙分发和密匙管理相对简单。缺点：加密和解密花费时间长、速度慢，只适合对少量数据进行加密。

散列函数是一种单向密码体制，指的是对信息进行加密，生成不可逆的固定长度的哈希值，一般用于完整性验证和数字签名场景，如验证数据在传输过程中没有被篡改。

总的来说，对称加密算法效率高，可以防窃听，但是要解决密钥交换安全问题；非对称加密的加解密效率低，适合用于认证，不适合用于内容传输，可以防窃听和防仿冒；散列函数不可逆的特性可以防止信息被非法篡改。

HTTPS将如上的技术整合，达到性能和安全的最大化。在HTTPS的交互流程中，客户端发起 HTTPS 请求，服务端返回CA证书，客户端对证书进行身份验证，验证通过后本地生成用于对称加密算法的随机数，通过CA证书中提取的服务器公钥对随机数进行加密传输到服务端，服务端接收后通过服务器私钥解密得到随机数，之后的数据交互通过对称加密算法，使用随机数生成的对称密钥进行加解密。

HTTPS通过非对称加密算法防止”中间人“攻击，同时可以为网站提供身份证明，并通过对称加密对HTTPS 的内容传输进行加密。

1.2 HTTPS 加解密与数据传输流程

简单来说，HTTPS业务的加解密和数据传输流程可以分三个阶段：证书验证、密钥交换、数据交换。

从上图可以看出：

数据交换阶段主要用于应用系统业务数据的加解密，也就是我们常规理解的数据加密，而该阶段的对话密钥是通过密钥交换阶段计算生成的，对称加密算法实现了业务数据的高效加解密。

密钥交换阶段实现了对称密钥在不安全环境的安全交换，如DH算法，就是利用离散对数计算问题，通过对方的公开值和自己的私有值计算出对称密钥，实现密钥安全交换。

证书验证阶段通过CA证书和数字签名，验证服务器身份，此处使用了非对称加密和散列函数算法，防止用户文件被篡改或伪造。

二、为什么有证书和私钥，还是看不了加密镜像流量？

在这里，回到最开始的第一个问题“针对现有HTTPS的业务，将加密流量通过镜像的方式发给安全设备探针，安全设备即使导入了证书和服务端私钥也没法解析出业务数据内容”，我们可以发现关键节点在于密钥交换环节，如果我们能够通过服务器私钥或者其他某种方式，将密钥交换环节中的保密随机数进行解析，就能获得整个数据交换环节的业务数据内容。

显然，通过RSA算法进行密钥交换时，只要中间人拿到服务端私钥就可以实现明文解包，也就是说，如果我们的HTTPS业务使用的密钥交换算法是RSA，是可以将加密镜像流量进行解密的，那为什么实际业务中解密不了呢？

如上图， DH的加密算法创造的目的就是防止这种解密方式，所以只要了解DH的原理，就能回答这个问题。

三、DH 算法原理介绍

简单来说DH算法是双方协商用同一个大素数p和 素数p的原根q，各自生成随机数X,Y。请求方将q的X次方mod p产生的数值发送给接收方，接收方将q的Y次方mod p产生的数值发送给请求方。请求方再对接收的数值做X次方运算，接收方对接收的数值做Y次方运算，最终生成一样的共享密钥，完成密钥的交换。

①A发给B：A的公钥

②B根据A的公钥，创建只针对A使用的公钥（AB-公）和私钥（AB-私）

③B发给A：AB-公

④A用自己的私钥和对方的公钥算出S：A的私钥+AB-公=S1=S

⑤B用自己的私钥和对方的公钥算出S：AB-私+A的公钥=S2=S

⑥A和B交互的数据，都可以用S解密。所以此时双方就可以正常加密通信了。

举个例子

①首先A和B协商一个随机二元组，q.p（3.7）。

A和B各自在（1，p-1）中取一个随机保密数da、db

并根据da、db算出pa、pb。

A和B所属范围（1,6）——da=05、db=6

pa=q^da mod p = 3^5 mod 7 = 5

pb=q^da mod p = 3^6 mod 7 = 1

②a和b对pa、pb值进行交互，并计算出共享秘钥S

S=pb^da mod p = pa^db mod p = 1

3.1 DH 如何防止流量被劫持后暴力破解解密？

中间人劫持流量能够拿到的信息有：q.p（3.7），pa、pb。中间人只需要算出da或者S就能对流量进行解密了。所以题目变成了：

已知公式：pa=q^da mod p，S=pb^da mod p

已知数：q、p、pa、pb

已知范围：da（q.p-1）

求S的值。

我们设N为mod后的商，商一定为整数。则可以得知：

da=log（q）（p*n+pa） 因为da（q.p-1）

所以n的取值范围为：（q^q-pa）/p到（q^（p-1）-pa）/p

因为pa是除以p的余数所以pa<p，可以忽略不计。

n的取值范围约等于q^q/p到（q^（p-1））/p

最终算出公式：s=pb^log(q)(p*n+pa) mod p，其中q、p、pa、pb为已知数，n为已知范围内的整数，看上去只需要进行遍历就可以破解秘钥了。

用q.p(3.7)套进去计算发现：

n为1-103 ，s唯一值=1,

但是当用q.p(3.1004535809)套进去计算发现：

n约有3^1004535809个，通过暴力破解的方式计算出来已经失去了时效性。甚至当p值更大时，这个值已经无法计算了。

四、哪些情况下可以实现旁路解密

在目前实际HTTPS业务中，基本采用DH类具备前向安全性的密钥交换算法，所以通过服务端私钥解密的方式在目前基本行不通了，如下图是一个实际HTTPS业务从浏览器看到的内容，可以看出密钥交换算法是ECDHE（DH的升级版），签名加密算法是RSA，会话加密算法是AES。

回到最开始的第二个问题，“众多安全厂商宣称其Tap镜像网、数据防泄漏、邮件审计、流量分析产品有旁路解密方案，又是如何做到的？”。我们来看看某厂商的《xx产品解密算法说明》。

可以发现，里面列了一长串的支持协议，但是用于解密的关键——密钥交换协议都是RSA，如果用了dh之类的前向安全协议，旁路就解密不了，这个场景在现在来看还是比较少见的。

五、结论与测评落地

对应控制点：GB/T 22239-2019 8.1.4.7 数据完整性 a)b)、8.1.4.8 数据保密性 a)b)

判定要点：传输环节采用校验或密码技术且算法与密钥长度满足现行要求（不使用 SSLv3/TLS 1.0/1.1、RC4、3DES、MD5、SHA1 签名证书），存储环节有哈希基线或加密措施，密钥管理可控 → 符合；协议版本或算法强度不足、可协商降级、仅部分链路加密 → 部分符合；传输存储均无保护或使用已废弃算法 → 不符合。

取证要求：协议版本与密码套件实测输出（openssl s_client、抓包 ClientHello/ServerHello）、证书链与签名算法、加密配置与密钥管理截图、哈希基线与比对记录、算法选型说明。

5.1 旁路解密的适用边界（结论）

密钥交换方式旁路镜像 + 服务端私钥能否解密说明
RSA 密钥交换（TLS 1.0~1.2，已废弃）可以会话密钥由客户端用服务端公钥加密传输，持有私钥即可还原
静态 DH（含静态 ECDH）可以（需长期私钥）实践中极少使用
临时 DH/ECDHE（当前主流）不可以具备前向安全性，会话密钥仅存在于通信双方内存，私钥无法还原
TLS 1.3不可以1.3 已移除 RSA 密钥交换，仅保留 (EC)DHE

因此：声称"旁路镜像即可解密 HTTPS"的方案，仅在服务端仍使用 RSA 密钥交换时成立； 在 ECDHE/TLS1.3 环境下，旁路设备只能做不解密的元数据分析（JA3/JA3S 指纹、SNI、证书链、 流量时序与包长特征、行为基线偏离），无法还原业务内容。

5.2 若确需内容级审计，可行路径

  1. 正向代理/反向代理解密：由 WAF、负载均衡或反向代理终结 TLS，解密后将明文流量镜像给检测设备 （这是具备解包能力的产品能"解密"的原因——它本身就是通信一端）；
  2. 客户端侧代理：终端安装代理证书，由客户端代理完成解密与再加密；
  3. 服务端日志与 APM 侧取证：以应用自身的访问日志、数据库审计替代流量侧内容还原。

5.3 现场核查命令：确认实际协商的密钥交换算法

# 查看服务端支持的协议与握手结果（关注 Negotiated TLS version 与 Cipher）
openssl s_client -connect <host>:443 -servername <host> -tls1_2 < /dev/null 2>/dev/null \
  | grep -E "Protocol|Cipher|Verify return code"

# 直接判定：出现 ECDHE / DHE 即为临时密钥交换（前向安全），旁路无法用私钥解密
openssl s_client -connect <host>:443 -servername <host> < /dev/null 2>/dev/null \
  | grep -oE "(ECDHE|DHE)-[A-Z0-9-]+|^ *Cipher *: *[A-Za-z0-9-]+"

# 批量核对多个域名/端口（逐行输出：域名 协议 套件）
while read -r h; do
  c=$(echo | openssl s_client -connect "$h:443" -servername "$h" 2>/dev/null | grep -m1 "Cipher *:")
  echo "$h -> $c"
done < hosts.txt
  • 判定提示：输出中 Cipher 含 ECDHE/DHE → 前向安全，旁路私钥解密不可行； 若为 AES256-SHA（无 ECDHE/DHE 前缀）→ 使用 RSA 密钥交换，属应整改的弱配置（TLS 1.0/1.2 时代遗留）。

5.4 版本适用性对照

TLS 版本密钥交换旁路可解密性测评提示
TLS 1.0（已废弃）RSA / DH / ECDHE 可选视套件而定协议本身即不符合，应判不符合并整改
TLS 1.1（已废弃）同上同上同上
TLS 1.2RSA / ECDHE 可选仅 RSA 套件可应强制 ECDHE 套件并禁用 RSA 密钥交换
TLS 1.3仅 (EC)DHE否（前向安全强制）推荐目标；同时需确认旁路设备的检测方式已调整为不解密分析

参考依据

  • GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》（8.1.2.2 通信传输 a)b)、8.1.4.7 数据完整性 a)、8.1.4.8 数据保密性 a)（加密流量的测评方法与适用性判定））：http://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=BAFB47E8874764186BDB7865E8344DAF
  • GB/T 28448-2019《信息安全技术 网络安全等级保护测评要求》（测评对象边界认定、单元测评实施与结果判定：符合/部分符合/不符合/不适用）：http://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=7E736CDF4502B6FF1258DD250AA3EC8C
  • GB/T 22240-2020《信息安全技术 网络安全等级保护定级指南》、GB/T 25070-2019《安全设计技术要求》、GB/T 28449-2018《测评过程指南》，可在全国标准信息公共服务平台检索：http://openstd.samr.gov.cn/bzgk/gb/
  • RFC 8446·The Transport Layer Security (TLS) Protocol Version 1.3：https://datatracker.ietf.org/doc/html/rfc8446
  • OpenSSL 官方文档入口：https://docs.openssl.org/
  • Mozilla·Server Side TLS 配置建议（协议与密码套件现行口径）：https://wiki.mozilla.org/Security/Server_Side_TLS
  • 《网络安全等级保护测评高风险判定指引》（中关村信息安全测评联盟团体标准）——高风险情形判定口径，站内对照表：22、高风险判定指引与加固对照表
  • 命令核验说明：本文的协议原理与算法口径以 RFC 8446（TLS 1.3）、OpenSSL 官方文档与 Mozilla Server Side TLS 现行建议核验（核验日期 2026-09-02）。四处须留意：① TLS 1.3 已移除 RSA 密钥交换与静态 DH，仅保留 (EC)DHE，前向保密为强制属性，因此「向审计设备导入服务器私钥即可解密镜像流量」的做法在 TLS 1.3 下原理上不可行，不得据此判被测单位不符合；② TLS 1.2 及更早版本若协商到 TLS_RSA_* 密码套件，导入私钥的旁路解密仍可行，须以现场 openssl s_client 实测协商结果为准；③ openssl s_client 的 -cipher/-tls1_2 等选项在 OpenSSL 1.1.1 与 3.x 间行为一致，但 3.x 默认安全级别（SECLEVEL）会拒绝过弱套件，报错不代表服务端不支持，须加 -legacy 或降低安全级别复测；④ SSLv3、TLS 1.0/1.1 已被主流浏览器与监管口径废弃，现场发现仍启用应同时记录 8.1.4.8 a) 的高风险线索。

关联文章