从Delphi中的缓冲区检测Quic协议?

发布于 2025-02-03 00:23:40 字数 271 浏览 4 评论 0原文

我正在Delphi中有一个可以监视UDP流量的应用程序。检测何时使用QUIC协议的正确方法是什么?我将数据放在tbytes缓冲区中。

QUIC RFC: https://datatracker.ietf.org.org.org/doc/doc/doc/html/html/rfc9000

I am having an app in Delphi that monitors UDP traffic. What is the proper way to detect when a QUIC protocol is used? I have the data in a TBytes buffer.

QUIC rfc: https://datatracker.ietf.org/doc/html/rfc9000

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

昇り龍 2025-02-10 00:23:40

根据您要寻找的积极匹配的程度,“公园里的步行”和“一点点噩梦”之间的努力各不相同。

Quic具有复杂的握手,在此过程中,加密密钥被得出,然后移至完全加密的应用程序数据阶段。最重要的是,该协议还旨在允许在交换过程中迁移端点(例如在WiFi和移动数据之间跳跃的移动设备),因此,简单地跟踪IP地址和端口不会捕获所有内容。

如果您想要的只是对要启动的Quic连接的基本检测,那么您需要做的就是寻找具有清晰格式的初始数据包,并且仅被混淆(未加密)。

rfc9000

17.2.2.  Initial Packet

   An Initial packet uses long headers with a type value of 0x00.  It
   carries the first CRYPTO frames sent by the client and server to
   perform key exchange, and it carries ACK frames in either direction.

   Initial Packet {
     Header Form (1) = 1,
     Fixed Bit (1) = 1,
     Long Packet Type (2) = 0,
     Reserved Bits (2),
     Packet Number Length (2),
     Version (32),
     Destination Connection ID Length (8),
     Destination Connection ID (0..160),
     Source Connection ID Length (8),
     Source Connection ID (0..160),
     Token Length (i),
     Token (..),
     Length (i),
     Packet Number (8..32),
     Packet Payload (8..),
   }

来自 QUIC版本1初始数据包将检查以下(psuedocode):

( packet[ 0 ] & 0xf0 ) == 0xc0
packet[ 1 ] == 0x00
packet[ 2 ] == 0x00
packet[ 3 ] == 0x00
packet[ 4 ] == 0x01

如果您想超越此功能,它很快就会变得更加复杂。

我强烈建议您下载和运行 wireshark ,并亲自查看电线上的外观。

Depending on how much of a positive match you're looking for, the effort varies between "walk in the park" and "a bit of a nightmare".

QUIC has a complex handshake, during which the encryption keys are derived, and then it moves into the fully-encrypted, application data phase. On top of this, the protocol is also designed to allow migration of endpoints during the exchange (such as a mobile device jumping between wifi and mobile data), so simply tracking IP addresses and ports isn't going to catch everything.

If all you want is basic detection of QUIC connections being initiated, then all you need to do is to look for the initial packets, which have a clear format, and are only obfuscated (not encrypted).

From RFC9000:

17.2.2.  Initial Packet

   An Initial packet uses long headers with a type value of 0x00.  It
   carries the first CRYPTO frames sent by the client and server to
   perform key exchange, and it carries ACK frames in either direction.

   Initial Packet {
     Header Form (1) = 1,
     Fixed Bit (1) = 1,
     Long Packet Type (2) = 0,
     Reserved Bits (2),
     Packet Number Length (2),
     Version (32),
     Destination Connection ID Length (8),
     Destination Connection ID (0..160),
     Source Connection ID Length (8),
     Source Connection ID (0..160),
     Token Length (i),
     Token (..),
     Length (i),
     Packet Number (8..32),
     Packet Payload (8..),
   }

So a quick and dirty way of detecting a QUIC version 1 initial packet, is to check for the following (psuedocode):

( packet[ 0 ] & 0xf0 ) == 0xc0
packet[ 1 ] == 0x00
packet[ 2 ] == 0x00
packet[ 3 ] == 0x00
packet[ 4 ] == 0x01

If you want to go beyond this, it quickly gets exponentially more complicated.

I'd strongly recommend downloading and running wireshark and seeing for yourself what it looks like on the wire.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文