 | 1 | initial version |
Hello,
It seems I found the reason. It seems Version 3.2.5 only support QUIC draft-28. If I use QUIC draft-29, this decrypt fail issue occur. If I fallback to QUIC draft-28, the issue gone. Compare the draft-28 with draft-29 of wireshark output as below. It seems version 3.2.5 can't support 2bytes length which indicate by "Packet Number Length" in Long Header Packets(byte 0, field mask 0x03)?
Draft-29(decrypt fail):
QUIC IETF
QUIC Connection information
[Packet Length: 1200]
1... .... = Header Form: Long Header (1)
.1.. .... = Fixed Bit: True
..00 .... = Packet Type: Initial (0)
.... 11.. = Reserved: 3
.... ..01 = Packet Number Length: 2 bytes (1) <=================== 2 bytes length
Version: Unknown (0xff00001d) <=============================== draft-29
Draft-28(decrypt success):
Frame 9: 211 bytes on wire (1688 bits), 211 bytes captured (1688 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 192.168.1.19 (192.168.1.19), Dst: 192.168.1.16 (192.168.1.16)
User Datagram Protocol, Src Port: 8341 (8341), Dst Port: 38674 (38674)
QUIC IETF
QUIC Connection information
[Packet Length: 167]
1... .... = Header Form: Long Header (1)
.1.. .... = Fixed Bit: True
..00 .... = Packet Type: Initial (0)
.... 00.. = Reserved: 0
.... ..00 = Packet Number Length: 1 bytes (0) <=================== 1 bytes length
Version: Unknown (0xff00001c) <=============================== draft-28
Destination Connection ID Length: 20
Destination Connection ID: 664b0040a048bd41027136fae6ca447ff87246ae
Source Connection ID Length: 20
Source Connection ID: 9e8a9d15b2b8b971f3d8f239a9285f411d4432be
Token Length: 0
Length: 117
Packet Number: 0
Payload: ccfd69c9a403b5a46eae2c0df8903988f43d7744210305fe…
ACK
TLSv1.3 Record Layer: Handshake Protocol: Server Hello