[FR] HTTPS collection supports hooking BoringSSL library functions (Envoy & Istio mTLS)

[fyuan1316]

Search before asking

• [X] I had searched in the issues and found no similar feature requirement.

Description

当前 DeepFlow 针对 Istio 服务网格可观测需要将 mtls 关闭，见： 部署istio。实际生产环境中大多不会禁用，这样就会导致 网卡层面 tls 加密信息无法被正确解析、关联。

直接的影响有：

1. 调用链 Flame Graph 中 span 信息可能出现丢失的情况（例如：curl 访问三个服务 curl->A->B，在火焰图中只能看到 curl->A，A->B 的span信息没有关联出来 ）
2. 在 tls 通信的网卡之间，网卡的span 无法观测到

case-1： curl->s-1->s-2 , s-2 服务在火焰图上断链

case-2：服务的 「网卡 span」 信息缺失

对比 关闭 mtls 后的 正常火焰图

---

对于case-1 来说，我们可以加入一些辅助信息，来帮助 DF 识别 同一条 trace，比如，上图caes-2中已经可以做到的效果。 但是对于 服务网卡 span 信息缺失，目前还没有找到好的 walkaround（对比正常的 火焰图，可以清楚看到差异）

通过发掘源码和文档，我们发现DF提供了openssl uprobe 用来支持 加密通信的场景，但经过测试发现对istio mtls开启场景是没有效果的。

进一步发现，这里的代码实现似乎最终是在对 openssl 动态库做 uprobe，这样的话 openssl uprobe 没起效果似乎就说的通了（我们知道 envoy 是静态链接了 boringssl）。 https://github.com/deepflowio/deepflow/blob/cd319550b591c927ec8da76ed56d6c22ac842047/agent/src/ebpf/user/ssl_tracer.c#L226-L239

基于以上，期望 DeepFlow 能进一步支持 istio 开启mtls 的可观测应用场景。

Use case

No response

Related issues

No response

Are you willing to submit a PR?

• [ ] Yes I am willing to submit a PR!

Code of Conduct

• [X] I agree to follow this project's Code of Conduct