Ask Your Question
0

QUIC payload can't be decrypted

asked 2020-07-10 09:17:22 +0000

updated 2020-07-10 09:20:16 +0000

grahamb gravatar image

output key in a file(attachment: sslkey.log), and set this sslkey.log into "(Pre)-Master-Secret log filename". The quic payload can't be decrypted.

As I can't upload file, paste sslkey.log content here:

CLIENT_HANDSHAKE_TRAFFIC_SECRET e0e059352a2fae884377a78c6c8cffd86b97ea726bec0929c369e843e69358db db897d397b6258be06736bbab7332634e544383f64027aff6d5880b84ab2b453
SERVER_HANDSHAKE_TRAFFIC_SECRET e0e059352a2fae884377a78c6c8cffd86b97ea726bec0929c369e843e69358db 649863acd76034ebcc518b889973520579e53e1df8fdc1066e772600ebb5264d
CLIENT_TRAFFIC_SECRET_0 e0e059352a2fae884377a78c6c8cffd86b97ea726bec0929c369e843e69358db b4776f4598fddf5bddff5c9561d872356714b12103e22c792ec70adcb33ff888
SERVER_TRAFFIC_SECRET_0 e0e059352a2fae884377a78c6c8cffd86b97ea726bec0929c369e843e69358db 6617c80b40303972c960da9ac03e5490c72c946a162a2dff5727ad715e8613a0
EXPORTER_SECRET e0e059352a2fae884377a78c6c8cffd86b97ea726bec0929c369e843e69358db 6032cc68df47eecc384ba3354e2844a8c736af41aafc79fac2c6e9d9df462577

I also set the tls debug out, from the log:

trying to use TLS keylog in D:\mywork\bug\delta\sslkey.log
tls13_get_quic_secret Cannot find QUIC SERVER_HANDSHAKE_TRAFFIC_SECRET of size 32..32, found bad size 0!
tls13_get_quic_secret frame 14 is_quic=1
trying to use TLS keylog in D:\mywork\bug\delta\sslkey.log
tls13_get_quic_secret Cannot find QUIC SERVER_HANDSHAKE_TRAFFIC_SECRET of size 32..32, found bad size 0!
tls13_get_quic_secret frame 16 is_quic=1
trying to use TLS keylog in D:\mywork\bug\delta\sslkey.log

It seems wireshark can't read out the key from sslkey.log.

edit retag flag offensive close merge delete

Comments

My wrieshark version: Version 3.2.5 (v3.2.5-0-ged20ddea8138)

cooldex gravatar imagecooldex ( 2020-07-10 09:18:33 +0000 )edit

And the TLS client generating the sslkey.log file?

grahamb gravatar imagegrahamb ( 2020-07-10 09:20:54 +0000 )edit

The sslkey.log and corresponding wireshark log is collecting from client side. I just take a look packet-tls.c. Base on the deubg log: tls13_get_quic_secret Cannot find QUIC SERVER_HANDSHAKE_TRAFFIC_SECRET

Wireshark seems this is from server side? why??

tls13_get_quic_secret(...){ ...

 case TLS_SECRET_HANDSHAKE:
     if (is_from_server) {
         label = "SERVER_HANDSHAKE_TRAFFIC_SECRET";

... }

cooldex gravatar imagecooldex ( 2020-07-10 09:27:46 +0000 )edit

1 Answer

Sort by » oldest newest most voted
0

answered 2020-07-12 10:40:42 +0000

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
edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2020-07-10 09:17:22 +0000

Seen: 174 times

Last updated: Jul 12