eCapture新版性能提升10倍,支持openssl 3.2

admin 2024年1月29日20:56:32评论22 views字数 2702阅读9分0秒阅读模式

eCapture是什么

eCapture旁观者[1]一个无需CA证书,无侵入的HTTPS/TLS明文抓包工具。可以在Linux 4.18以上版本使用,同时也支持Android arm64 5.5以上版本。

年底打脸

记得8月份时,在GitHub万星项目进度70%,eCapture旁观者7K Stars达成一文中吹牛说到,年底冲1万颗星,奈何平时工作特别忙,根本没时间堆新功能,年底一看,果然打脸了,只有7.8K星,

eCapture新版性能提升10倍,支持openssl 3.2

不过,笔者也一直忙里偷闲地回复社区的问题,不停地修复程序bug。

增加难度

这不,有几个小朋友给我提出了新的挑战,在生产环境,上万QPS的7层负载均衡,启用eCapture,会有什么样的结果?性能扛得住吗?

性能提升10倍

有用户在社区反馈eCapture性能问题TLS 模式下,对被检测程序的性能影响[2],执行一千万次SSL_write写数据的场景,不开启eCapture耗时6秒,而开启eCapture后却要30秒,性能耗时增大5倍以上。

eCapture新版性能提升10倍,支持openssl 3.2

这个数字就很尴尬,就在你潇洒的这两天,笔者全身心投入,用爱发电,翻阅OpenSSL源码,终于有了很大的进展。

进步大是因为起点底

笔者分析了OpenSSL类库中,以ServerClient两种模式,分别选择合适的HOOK函数,减少SSL_writeSSL_read两个函数高频调用下的触发机制,最终把耗时从30秒降低到7秒。整体来看,进步特别大。但原来确实有偷懒,直接用了SSL_write函数。

eCapture新版性能提升10倍,支持openssl 3.2

继续宠粉

又有小朋友在社区提了issue:The SSL structure in openssl 3.2.0 has been modified[3],里面提到OpenSSL 3.2.0[4]已发布了,而且核心ssl_st结构体发生很大变化,eCaptuer捕获TLS通讯密钥的功能无法使用。

eCapture新版性能提升10倍,支持openssl 3.2

笔者确认了一下,OpenSSL 3.2.0是2023年11月底发布的,至今不过2个月时间,应该还没有多少大型应用使用,不过,笔者就是喜欢宠粉,立马给安排了。谁让这位小朋友的issue写得漂亮呢。

eCapture新版性能提升10倍,支持openssl 3.2

新版下载

无CA捕获TLS明文软件eCapture v0.7.3[5]版发布,性能提升10倍,千万次调用增加2秒,支持openssl 3.2。

eCapture新版性能提升10倍,支持openssl 3.2

Warning

以下为技术原理,可以不用看。

技术实现

性能优化

设计思路

问题

  • 为了读取到TLS握手完成后的client_random等密钥,必需要选择一个合适的HOOK函数。
  • SSL_writeSSL_read时,TLS握手是建立完成的,但调用过于频繁,会带来性能问题,参见 #463
  • 综合来看,合适的HOOK函数需要满足以下几个条件:
    1. 函数是在TLS握手完成后调用
    2. 函数名在动态链接库的符号表中是导出状态
    3. 函数是低频调用

解决思路

  • 在 openssl 类库中,以客户端角色调用 SSL_connect 或者以服务端角色 SSL_accept ,最终都会进入 ssl/statem/statem.cstate_machine 函数进行TLS握手。
  • 所以,可选范围是在这个函数内以大写SSL开头的函数。
  • 当使用openssl的方式为同步调用时,TLS握手成功会返回1,也就是ret = 1,即需要在这个变量赋值后,被调用的函数,才能拿到符合要求的内存数据。state_machine函数内符合要求的就只有SSL_get_wbio了。
  • 当使用openssl的方式为异步 (BIO)调用时,还需要增加SSL_in_before函数。
masterKeyHookFuncs = []string{
  "SSL_get_wbio"// openssl client mode
  //"SSL_is_init",  // boringssl client mode
  // 备用HOOK 函数
  //"SSL_is_init_finished",
  "SSL_in_before"//openssl client mode
  "SSL_do_handshake"// openssl server mode
 }

OpenSSL 3.2.0

无它,翻阅OpenSSL源码,分析差异,重新实现密钥提取代码,详情见 PR 472[6] 。不过,新版里新增了对QUIC TLS的支持,eCapture暂时没支持,预计春节后安排。

// TODO 检查 ssl->type, 参考 ssl/ssl_local.h的 SSL_CONNECTION_FROM_SSL_int 宏
    int type;
    if (type == SSL_TYPE_QUIC_CONNECTION) {
        // Reget the address of the ssl->tls as the address of the SSL_CONNECTION
        debug_bpf_printk("unsupported type: SSL_CONNECTION, coming soon.n");
        return 0;
    }

届时,eCapture就可以无需CA证书,即可捕获QUIC TLS的明文内容了,敬请期待。

红包封面预告

去年封面

即将春节,送给大家一些手绘的红包封面,依旧由去年红包封面《烤火兔》的设计大师,外甥女S负责。

eCapture新版性能提升10倍,支持openssl 3.2

今年封面

本次春节红包封面《龙"码"精神》,依旧没有任何广告、品牌标识。仿版画风格,材质感更重。

立寒冬,暖阳待雪,龙码精神!这款红包风格采用木质版画风格,五行之中黑色对应水,遇水则发~黑龙俯卧在金灿灿的摇钱树给大家送福啦!

eCapture新版性能提升10倍,支持openssl 3.2

参考资料
[1]

eCapture旁观者: https://ecapture.cc

[2]

TLS 模式下,对被检测程序的性能影响: https://github.com/gojue/ecapture/issues/463

[3]

The SSL structure in openssl 3.2.0 has been modified: https://github.com/gojue/ecapture/issues/464

[4]

OpenSSL 3.2.0: https://github.com/openssl/openssl/releases/tag/openssl-3.2.0

[5]

eCapture v0.7.3: https://github.com/gojue/ecapture/releases/tag/v0.7.3

[6]

PR 472: https://github.com/gojue/ecapture/pull/472

原文始发于微信公众号(榫卯江湖):eCapture新版性能提升10倍,支持openssl 3.2

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2024年1月29日20:56:32
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   eCapture新版性能提升10倍,支持openssl 3.2https://cn-sec.com/archives/2440179.html

发表评论

匿名网友 填写信息