原文首发在：先知社区

https://forum.butian.net/share/3866

这篇文章从一个略懂密码学的安全分析工程师的角度围绕加密流量检测的问题开展详细的分析；让每一位读者明白加密流量的检测原理，以及目前市面上常见的检测方法落地。

0x01 背景

这篇文章从一个略懂密码学的安全分析工程师的角度围绕加密流量检测的问题开展详细的分析；让每一位读者明白加密流量的检测原理，以及目前市面上常见的检测方法原理。

为什么突然想写这么一篇文章呢，事情的起因是周四看了xx公司的新产品发布会：《轻解密——加密流量检测产品》。

其实早在2022年的时候，笔者曾写过一篇文章，里面提到了对于加密流量的检测原理以及方法，但是由于那篇问题涉及一些其他的敏感东西被噶了，正好就这个机会我把之前文章中的对于加密流量的相关部分也腾挪过来。

0x02 分析

一、加密流量分类

从一个安全分析工程师的威胁分析的角度笔者这里把加密流量分为两大类的：

• 1、以SSL协议为代表的加密通信流量

• 2、以冰蝎webshell管理为首的常见安全工具相关的及数据传输业务相关加密流量

简单的说，第一种是大家公认的数据传输加密协议；第二种是应需求而生的各应用自己私设的相关加密数据传输。

二、加密流量的威胁检测

对于加密流量的威胁检测，从检测位置来看可以分为两种，一种是串连在网络结构中，一种是旁路部署在网络结构中；串联这种解决方案其实就是密码学里面所说的中间人攻击（MITM）;双向欺骗，欺骗客户端我们是服务端，欺骗服务端我们是客户端；在中间传话即可（和渗透场景中的代理抓https包一样的原理）。但是其短板也非常明显，就是需要串联部署在网络结构里面，如果设备出问题了，整个网络都会受影响，所以使用一定要谨慎并做好备份处理以及应急解决方案。

本文我们主要来讨论另一种检测方案即旁路部署的方案实现加密流量的威胁检测

我们来谈谈目前对于上述两种类型的加密威胁检测方法

对于第一种：以SSL协议为代表的加密通信流量

使用解密的方法来实现这以类型加密流量的威胁检测，其实很多ids类产品的探针会有此项功能，主要支持用户处的tls（http+ssl：https）流量的威胁检测，需要用户导入对应https网站的证书以及私钥；

这里笔者来尝试说清楚其中的原理，当尽量不牵扯复杂的密码学知识；

为什么需要用户导入公钥和私钥呢？

以tls1.2举例，我们先来了解其通信的整个过程，笔者将其简化为4步：

1、客户端对服务端发送请求：你好我要和你建立链接

2、服务端收到请之后发送，自己的证书给客户端：好的，你要和我建立链接你就按协议预设好的计划行事把，这是我的证书

3、客户端收到服务端的证书，拿到证书中的权威机构对相关内容的签名，然后使用内置在电脑上的各根权威机构的公钥对该签名进行校验，确认该证书的确是对应的服务器端；确认之后就获取证书中的公钥的；然后自己随机生成一个密钥，使用从证书中获取的公钥对该密钥加密，传输给服务端：好的，我先验验你这个证书，确认没问题了我就给你发我们之后交流使用的对称加密密钥，发的时候就使用你给我的公钥加密；

4、服务端收到客户的加密内容，使用私钥对加密内容解密，从而拿到了对称加密密钥，从而开始传输真正的要传输的内容，并且是使用这个对称加密密钥来加密：好的，我们之后就正常使用http通信，但是记得把通信内容都使用对称加密处理，密钥就用刚刚你给我传的那个；

如下图。

然后我们回到之前的问题：为什么需要用户导入公钥和私钥呢？

上面的第三步里面我们可以看到，客户端发送了一个被加密的密钥给服务端，加密的方式使用服务端证书里面的公钥加密的；也就是流量中我们是可以直接看到这个内容的；所以此时只要我们有了服务端的私钥，那么就可以使用私钥对该内容进行解密；从而拿到里面的由客户端生成的，并且之后会用于加密通信内容的对称加密密钥；那么只要有了这个对称加密密钥，之后所有的通信流量都可以直接使用这个密钥解密，检测设备可以透明的看到里面的http流量；从而实现了对加密流量的威胁检测。

这里我们简单思考几个问题：

1、为什么要搞这么复杂，既然客户端都使用公钥加密对称密钥传输给服务端了，直接使用公钥加密后续的通信流量给服务端不就行了；

答：这种想法完全没问题，只有有服务端私钥的人才能获取到具体解密后传输的内容；但是这里面需要考虑性能的问题，这就涉及对称加密和非对称加密的原理了，简单的来说计算机对相同长度的密文进行对称加密的速度是非对称加密的速度的百倍甚至上千倍；这是由于两种加密算法的性质决定的（这里还只是考虑了加密，解密更夸张，对称加密算法的加解密速度其实是相当的，但是非对称加密算法，其解密通常要涉及高位数的运算从而其解密比加密还要慢不少）。非对称加密算法都是基于单项陷门函数实现的，即数学界的相关问题的难解性，如非对称加密算法RSA是基于大整数难分解的数学难题；

总结下来就是，可以，但是使用前者对称加密更优；

2、服务端的证书里面有什么，证书到底有哪些内容？一会服务端公钥，一会权威机构签名乱七八糟的；

这个问题其实对没有专门学习过密码学的人来说是比较模糊的，但是我们只需要抓住一点即可知道证书中的主要内容，即证书是用来干什么的：

我们常见证书有两种性质，如下图，左边的是通过浏览器访问google下载的，右图是查看chrom软件的签名里面使用的证书；

从目的来看，证书其实就是证明你是你，你不是我，你也不是他；

那么就需要的那些东西来证明呢，

1、证书里面需要要你的基本信息对吧，如，如果是一家公司，那证书里面要记录公司名称，公司地址等等

2、需要生成一对公私钥，将公钥放入证书

3、需要有根证书或相关子机构使用私钥对你的证书进行签名，那不然谁来保证上面的信息的真实性呢，所以找了个权威来证明（这一步是需要花不少钱的）

4、证书的其他基本信息，谁颁发给你的，有效期多久（一般来说权威机构颁发的证书有效期不会超过三年，除非是非常稳定的大公司，因为一旦私钥泄露，证书里面公钥也报废了，证书也随即报废了，而且时间越长要缴纳的钱也越多），使用的签名算法是什么（后续验证的时候需要的使用）

5、还有一些其他的，如摘要算法等之类的，这些就比较偏了（有人可能会说上面好像没有提到所谓的摘要算法的使用，其实不然，一些细节里面是用了的，比如权威机构使用私钥对你提供的证书签名的时候，其本身不是对你的证书内容签名，而是对你证书内容的摘要进行签名，两种行为其实差不多，只要保证摘要算法没有的碰撞即可）

对于第二种：以冰蝎为代表的安全工具及相关业务加密流量的检测

这里我们假设要使用解密的方法来实现这以类型加密流量的威胁检测

以冰蝎举例，其流量走的是http请求体，使用AES对称加密传输，密钥更具版本不同略有不同，v2是通过协商创建，v3是通过硬编码到webshell中服务端中；

那么对于这种流量的解密其实是比较难做的，因为我们需要获取到aes的密钥；对于v2版本来说我们先要更具其他特征辨别该条流量是冰v2的链接流量，然后动态的从连接流量里面获取到aes的key。对于v3来说，这里先要辨别出该条流量是冰v3的流量，然后通过和终端上的agent类型设备联动获取到webshell的内容，提取密钥解密（又或者尝试使用硬编码的默认密钥），通过里面的一些内容特征，从而实现对该条流量的检测。

你仔细看上面的条件，你会发现这是一个伪命题，那就是从威胁检测的角度来说，我们如果要对这类加密流量进行威胁检测，前提都是我们先要辨别这个流量是对应的威胁的流量；那这就扯了，我都能辨别了还要你干啥。

所以我们见到对此类威胁的其实不是通过解密来做的，而是结合一些辅助特征+加密本身的特征，从而进行的威胁检测的；

如冰蝎，请求头字段弱特征特征（ct字段，cl字段的大小）、请求url特征、请求体参数名称特征，然后再加请求体本身是加密的特征（这里我们可以理解为对称加密算法的加密特征，有人可能会说对称加密算法有什么固定特征吗？如果硬要算的话其实也还是有的；这个我在22年的时候发布在先知上的一篇对加密webshell流量分析的文章中提到过，实战分析某红队魔改哥斯拉Webshell，如冰蝎使用的是AES对称加密算法，AES作为国际标准对称加密算法，其密文本身是具备非常优秀的随机性的，即我们不能通过密文观察出任何和明文有关的特征（严谨一点，填充不算算法的本身），表现到的字节上就是，如果当我们把密文转化成2进制，那么这里的01分布应该是趋向于对半开的，%50）。

分析到这，这不是挺好的吗，你说的两种类型的加密流量都能被检测

我们不妨想想ssl协议本身被发明出来是为了干什么的，是不是就是为了防止别人通过侧\旁信道获取到的真正的通信内容，那你这么搞，肯定不行呀；

ssl协议肯定不干呀，这不就是说ssl协议有漏洞吗，至少从协议设计的角度的，你需要保证你的协议本身的安全性不依赖于环境（就和现代加密算法的安全性是基于密钥保密，而非算法细节保密的原则一样），也就是说即使我在一个非常危险，被各种人监控的环境里面的，只要我正常使用你的协议，你就应该能保证我的安全性。这个和kerberos协议的设计初衷一样的，其假设的就是域内环境不安全；

DH密钥交换算法

于是ssl协议里面使用一种特殊的密钥交换算法，应运而生，上文我们提到的ssl里面交换密钥使用的RSA来传输的及加解密的；这种方法显然是不能对抗的通过私钥解密会话密钥，然后通过会话密钥解密对话内容的操作。SSl协议这里引入了新的密钥交换算法——DH密钥交换算法（全称是：Diffie-Hellman密钥交换算法）Diffie、Hellman是两个人名，这两位是公钥密码学之父，他们于1970发布了一篇叫《密码学新方向》的文章，从此拉开的公钥算法体系；

我们来简单的说下这个dh的密钥交换算法，尽量通俗易懂让大家理解；

Alice 和 Bob 两个人想要协商出一个密钥，用于后续的对称加密；

1、首先Alice 和Bob直接使用 明文商量，选择两个数，一个是p，一个是g，其中p是一个素数，g是模p的有限域上的原根；

这里我们简单解释下原根：

要判断一个数是否是原根，需要检查它是否可以生成群中的所有非零元素。如我们选p为7的时候，在模7下，群的元素是 {1,2,3,4,5,6}

我们选择的g需要满足，其g的k次 mod 7 能够挨个便利 上面的群元素集合

例如此时我们选择g为3

(3^1) mod 7 = 3 mod7 = 3

(3^2) mod 7 = 9 mod 7 = 2

(3^3) mod 7 = 27 mod 7 = 6

(3^4) mod 7 = 81 mod 7 = 4

(3^5) mod 7 = =243 mod 7 = 5

(3^6) mod 7 = 729 mod 7 = 1

那么我们就说3是mod7的有限域上的原根；

2、Alice 和Bob各自随机选择一个记a，b，然后各自计算 (g^a )mod p 、(g^b) mod p 分别记做A、B；然后分别将A、B发送给对方；

3、在收到对方发来的内容之后，Alice 计算B ^a mod p 、 Bob计算A^b mod p ；此时Alice 和Bob 就获取到的了一个相同的密钥；

Alice最后的内容是 B^a mod p ， B = （g^b） mod p ,所以Alice计算的结果是：（g^b）^a mod p = g^(ab) mod p；

Bob最后的内容是A^b mod p, A = (g^a) mod p ,所以Bob的计算结果就是：(g^a)^b mod p = g^(ab) mod p ;

所以这两个结果是一样的；

如下图：

我们来思考下，攻击者如何才能破解这个密钥交算法，从而获取到最终的协商的结果密钥；

攻击者知道 参数p和g，然后也知道A、B，求最终密钥；

最终密钥 的表现形式如下：

\=B^a mod p
\=A^b mod p
\=g^(ab) mod p

所以攻击者无论如何都是要获取到a或者b，才能计算出最终密钥的；

那么这个问题就转化成已知：A=g^a mod p ，并且也知道具体的A 和 p 和g 是否能计算出来a；事实上这就是非常有名的模素域上的离散对数问题；当p是一个大素数的时候，这个对数式是非常难解的（难解的程度取决于有限域的大小，也就是p的大小，在常见的使用场景中p通过是2048位及以上位数的大小），正向算非常简单，但是逆向算是解不出来的，也就是上文说的单项陷门函数。

这里我们来聊聊 DH和RSA的关键区别：

1、SSL中使用DH算法交换密钥，DH的私钥，每次会话建立的时候都是由双方自己随机生成；但是使用RSA算法交换密钥，RSA的私钥一直都是不变的，就是对应的证书里面公钥对应的私钥，这个私钥在换证书的前提下是修改不了的。那么这里面就衍生出来了一个概念，叫前向安全性；就是说，如果有天你的私钥泄露了，那么会对你之前的会话造成影响吗？我们先不说私钥怎么会被泄露是以何种形式何种方法泄露，显而易见，DH不会，但是RSA是绝对会的，这也是为什么现在的一些探针旁路部署的设备能够解密对应的ssl流量的原因；

2、密钥的安全，DH中我们不难看出其实私钥就是在协商对称密钥的一瞬间有用，只要把密钥协商出来之后的，我们之后就在也用不上那个私钥了，甚至可以直接销毁，这样也大大的增加了密钥的安全性，销毁之后谁都不知道了，谁都获取不到了。但是RSA不一样，之后的每个会话都需要这个RSA私钥来用于这个协商过程中（服务端解密使用），所以需要在服务端找一个地方专门存储私钥的。

事实上SSL中的DH也是这么做的，即在生成共享密钥的一瞬间就销毁掉本地私钥。

接下来我们来看我们最关注的问题；

三、为什么旁路设备解密不了SSL3.0（TLS1.3）的流量

无论是哪家厂商的旁路解密流量检测设备，其对某加密站点支持的时候，都会需要询问客户对应加密站点ssl中能支持使用的加密套件是什么，然后有些套件不支持就解密不了；其实你仔细观察，你会发现一个现象就是所有在https 中ssl协议里面使用的了带DH作为密钥交换算法的组件的站点，没有一家产品是支持的；就是因为DH你没办法传私钥，私钥都是机器自己随机生成的，协商密钥阶段生成对称密钥的一瞬间，机器就销毁了对应的私钥；并且其还是一次一密即每个会话都是随机生成新的各自的私钥；

那这和ssl3.0有什么关系呢？

ssl3.0为了增强ssl协议的安全性，其强制要求在3.0版本只能使用dh密钥交换算法来协商对称加密使用的密钥；

ssl的1.0和2.0中没有强制要求，但是有些站点的ssl在配置加密套件的时候，如果使用了dh来作为密钥交换算法，那么目前旁路设备都是不支持解密的；

一个颠覆大家认知的观点

笔者这里要提出一个颠覆大家认知的观点：严格意义上来说从理论上看旁路也是可以解密使用了DH算法实现密钥交换的SSL协议加密流量（不管是哪个版本）；

我们就这个问题开展以下分析：

在了解了上面的SSL过程以及DH的原理之后我们不难看出，想要解密使用了DH算法实现密钥交换的SSL协议加密流量，核心就是怎么获取到DH里面的私钥，并且因为DH是每个会话都重新生成私钥，那么我们需要获取私钥和会话的对应关系。那么怎么才能做到上面两点呢？

做到这两点其实也不难，

1、在要被监测的服务端上我们上一个agent，hook其openssl组件里面的一些实现，比如我们可以通过hook生成dh私钥的方法，将生成的私钥发送到我们的解密设备上；这样以来我们可以获取到私钥了；

2、在要被监测的服务端上我们上一个agent，我们需要利用这个agent，记录会话的标志以及该次会话使用的私钥，将这个映射关系发送到我们的解密设备上，设备就可以把之前记录的会话一一解密了；

通俗点说，你不是一次一密（dh的每个会话都是生成新的随机密钥）嘛，那我就把你所有的密钥获取到，并且记录密钥和会话的映射关系。这不就解密了嘛！

但是为什么目前厂商做不出来呢，笔者认为这个根本原因就是第二点的，第二点想要获取会话和密钥的映射关系是非常难的，你怎么去标记一个会话是一个问题，因为你最后需要去旁路设备上找到对应的会话的流量去解密的；还有一些其他原因，就是会话量大，性能和成本之类的因素也要考虑；

所以目前市面上任何旁路流量设备都解密不了ssl3.0的加密流量（以及任何使用dh作为密钥交换算法的ssl协议流量）

0x03 xxx

文章写到这，应该是差不多把这个事情分析清楚了，我们进入正题。

上面我说到我为什么会写这篇文章，事情的起因是周四看了xx公司的新产品发布会，真的给我气笑了；

宣传说他们能做到旁路解密各种ssl协议的加密流量，说实话当时他们说可以，我心头一颤，难道加密流量检测要变天了，（第一时间看了下他们公司的股价，准备全仓干满，哈哈哈），来年国际密码协会也要给颁发给诺贝尔级别的奖项了，我只能说这是颠覆性的；

如下是他们ppt里面的某页其中部分内容：

看到这个ppt的时候，我感觉有些不妙；（如果读者理解了我上面文章的分析，看到这个的ppt的内容，应该能明白我那一刻的心理变化）；

什么东西，椭圆曲线是什么东西？完犊子了；

首先如果读者看了上面的内容就会了解，能不能解密就是看ssl协议里面使用了dh算法作为密钥交换算法没，用RSA肯定是可以解密的；

给我整蒙了，然后这个讲的大哥也在重复的ppt上的面内容，说：“大家可能都知道的目前tls1.3的流量是解不了的，但是其解不了的核心原理可能较少的人知道，主要是因为椭圆曲线算法导致的解密不了，二这次我们的产品无论你是什么版本的tls，无论使用的是rsa还是椭圆曲线，都能解！“（原话我记不太清了，大致意思就是这么个意思）；

。。。。。

不是咱们这么大一厂，真就找不出来一个懂的人来说这个的发布会吗，技术人员去哪了，ppt也不审核下？这波技术人员全责（手动狗头）；

然后我们再来讲讲他说的椭圆曲线的算法是个什么东西，上文提到过笔者曾在22年发布一个文章，里面就写过这个，我这边直接引用之前文章里面的内容：

举个例子，DSA稍懂密码学的人应该都知道（不知道也没关系），其是一个非对称加密算法，其原理是基于模素域上离散对数难求解的难题。但是随着一些算法的研究，我们破解DSA的时候，就不再需要使用一一穷举的方法来破解，拿1024位的DSA算法举例，其安全等级还没128位的AES的安全等级高，而且这个随着这个位数增涨的趋势，DSA其安全等级想要增长一倍，其位数是呈指数增长的（可能要翻很多倍，比如：我们想要获得一个和256位的AES相同安全等级的DSA，那这个DSA的位数可能要五六千位，甚至上万位，反正数远大于2048位的）；就是因为这个原因，ECDSA才出现的（即基于椭圆曲线上的DSA算法），其原理变成了基于椭圆曲线上的点求椭圆曲线上的离散对数问题，因为椭圆曲线离散对数问题远难于离散对数问题，所以在引入了椭圆曲线之后，我们使用160位的ECDSA就和之前1024位的DSA具有相同的安全等级了，所以我们才引入了EC即椭圆曲线这一概念，DH和ECDH也是同样的关系。

（这个插一句，看完这个，大家应该都懂了dh是哪来的，dh其实就是dsa演变而来的，dsa本身是非对称加密算法，DH则是由其演变的一款密钥交换算法）

所以说xx公司发布会说什么椭圆曲线和能不能解密挂钩，真的太滑稽了。真就是外行人看热闹，内行人看笑话。稍微一个懂点密码学的技术人员都能懂里面的技术原理。

然后整场发布会，前面各种铺垫，层层递进说旁路能解任何流量，可以说是引人入胜。最后你猜怎么着，发布的产品是agent的形式，需要装到各个主机上。。。。

我就想问发布方一个问题：

你管agent形式部署叫旁路部署是吧；（感觉是乱入，根本不是一个概念的东西；况且严格意义上来说，agent里面如果对相关加解密函数进行hook了，又或者对服务处理逻辑进行hook了，这种也算是串联， 因为一旦你hook的点出了问题，那么整个业务流量也要遭）

其在发布会上没有说产品的实现原理，但是我们可以分析，其实如果能够装agent到端，那么解密这个事情就没这么难了，我们简单看看可以使用那些方法实现：

1、hook关键函数，hook服务应用对ssl整个过程的相关处理函数的，比如服务端在收到的客户端的加密内容之后https服务需要调用解密函数，毕竟内部的处理逻辑不认识加密数据，只能处理解密之后的http流量。那么我们只需要hook这里的解密函数，将解密后的每次会话内容存储到指定的位置即可。

2、上面笔者分析过就算使用了dh，理论上也可以实现解密，关键是需要找到密钥，以及密钥和会话的映射关系，如果他们找到这个处理第二点方法，那么也可以实现的解密。

大致思路应该就这两条路，笔者推测大概率还是使用的第一个条思路，如果可以直接在端上操作，其实现起来比第二条思路简单得多。

然后其实这样的事情无独有偶，之前22年的时候datacon 的某赛道冠军战队，在线技术交流会里面发的一个ppt里面也出现了类似的操作：

其在ppt上说 图元曲线算法相比RSA算法来说具有前向安全性。

首先我们要搞懂什么叫前向安全性，前向安全性是指，当我们在某一时刻获取获取到私钥的时候的，这个时刻的之前的会话是否还具备安全性，即是否会被解密；这个问题上面我们同样分析过，ssl协议中如果使用dh来交换密钥，每次会话都会使用的是新的随机生成的密钥，然后协商新的对称密钥；也就是所谓的一次一密，那你获取到这次的密钥，之前的完全不受影响的，所以也就具备了前向安全性；和所谓的椭圆曲线算法没一毛钱关系；

椭圆曲线不管用于dsa还是dh，其只有一个目的，就是上面说的能够在密钥选择相同位数的情况下使其单向陷门函数更加难被破解，从而在相同位数的密钥下能够提供更高的安全等级更高。

0x04 总结

被q到的公司和人无意冒犯，笔者也不是一个喜欢搞事的人，但是这也太离谱了，这不妥妥的把观众当傻子，唱独角戏嘛，个人觉得xx公司还算是行业内比较靠前的公司（比较牛），其情报平台笔者也一直在用了，我只说事，针对事，不针对人也不针对公司；其他个人的一些技术分享存在一些不正确的问题的话，我觉得情有可原把。

最后：希望我们这行每个技术从业者都能够的在自己合适的岗位大放光彩！不忘初心把。

后记

很多东西知其然不知其所以然，这样稀里糊涂的学习的是不可取的，我们应时刻保持好奇和求知，打破沙锅问到底，而不是人云亦云。

路漫漫其修远兮，吾将上下而求索

笔者才疏学浅，若文中存在错误观点，欢迎斧正。