QpointのqtapはプロキシなしでeBPF経由でTLS平文を読み取る

セキュリティ監査、APIデバッグ、統合作業はいずれも同じ壁に突き当たります。トラフィックはTLSで暗号化されているため、アプリケーションが実際に何を送信しているかを突き止めるには、通常は中間者プロキシを立ち上げ、証明書をインストールし、すべてのクライアントを再設定し、さらに改変した経路上でのレイテンシを受け入れる必要があります。

可観測性企業QpointのQtapは、暗号化が実際に起こる場所でこの問題に取り組みます。そのeBPFエージェントは各プロセスのバイナリとライブラリをスキャンしてTLSシンボルを探し、ユーザー空間プローブでSSL_readとSSL_writeをフックして、データを元の非暗号化形式で捕捉し、プロキシには決して見えないコンテキスト（プロセス、コンテナ、ホスト、ユーザー、プロトコル）を付加します。静的リンクされたプログラムはバイナリを直接プローブすることで処理され、メンテナーはローンチスレッドで、Goバイナリはバージョンごとに事前計算された構造体オフセットとELFスキャナでカバーされると説明しました。

その見返りは、インストルメンテーションなしの検査です。アプリケーションの変更なし、プロキシなし、証明書管理なし、そして最小限のオーバーヘッドで帯域外動作するという主張です。このプロジェクトは2025年5月にHacker Newsで259ポイントと78コメントを集めてローンチされ、カタログ作成時点でApache-2.0リポジトリは1.5kスターと289コミットを示し、Qpointは同じエージェント上に自社のegress可観測性製品を構築しています。

トラフィックが通過する場所ではなく、暗号化が始まる場所で平文を読む

SSL_readとSSL_writeをフックすることで、オブザーバーは平文が存在するまさにその場所に置かれるため、ワイヤー上で復号する必要がありません。

プロキシも証明書も不要であるため、レガシーシステム、サードパーティのバイナリ、短命なプロセスを一切触れることなく検査できます。

カーネルのビューはプロセス、コンテナ、ホスト、ユーザーのコンテキストを運び、ネットワークレベルのプロキシではこれを帰属できません。

トラフィックは再ルーティングされるのではなく観測されるため、アプリケーション自身の接続経路とレイテンシは変わりません。

デモモード付きでエージェントをオープンソース化したことで、コミュニティがこのアプローチを検証でき、Goバイナリの疑問が浮上し公開の場で回答されることになりました。

暗号化されたトラフィックは、それが生成される境界では平文です。そこでカーネルレベルの可視性をもって傍受すれば、アプリケーションを一つも変更することなく検査できます。

バッチがこのプロジェクトをカタログ化した時点で、qtapはApache 2.0ライセンスの下で1.5kスターと289コミットを示し、作者らは依然として初期開発段階と呼んでいました。リポジトリにはChrome DevTools風のWebインターフェース、OpenTelemetryのトレースとメトリクスのエンドポイント、サンプルのGrafanaダッシュボード、ワンコマンドのデモおよびインストールスクリプトが同梱されており、その背後にある企業Qpointは同じエージェント上にegressトラフィック向けのインベントリおよびアラート製品を構築しています。