First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
Ask Your Question
0

[ws 3.2.0] quic handshake is decrypted but subsequent packets are not

  • retag add tags

I'm trying to get an understanding of the QUIC protocol using wireshark (and other material from various sources).

Steps that I followed:

  1. captured (using tshark) QUIC traffic between a local client server (generated using mozilla/neqo, with SSLKEYLOGFILE env to store traffic secrets).
  2. set the captured traffic secrets path in wireshark preferences (Protocols -> TLS [(Pre)-Master-Secret log filename])
  3. open the pcap file

Expected:

  1. decrypted payloads for QUIC handshakes
  2. decrypted payloads for subsequent QUIC packets

Observed:

  1. [PASS] decrypted payloads for QUIC handshakes
  2. [FAIL] decrypted payloads for subsequent QUIC packets

Are there any additional steps that I need to follow to decrypt all QUIC packets?

screenshot showing the issue: wireshark-quic-screenshot

magesh's avatar
1
magesh
asked 2019-12-25 06:54:17 +0000, updated 2019-12-25 07:03:15 +0000
edit flag offensive 0 remove flag close merge delete

Comments

(This question was cross-posted at https://www.wireshark.org/lists/wireshark-users/201912/msg00009.html)

Lekensteyn's avatar Lekensteyn (2020-01-03 13:52:45 +0000) edit
more
  • delete
add a comment see more comments

2 Answers

0

Hi,

Please open a issue on bugtracker and attach pcap and SSLKEYLOGFILE

Alexis La Goutte's avatar
110
Alexis La Goutte
answered 2020-01-02 06:38:48 +0000
edit flag offensive 0 remove flag delete link
more

Comments

add a comment see more comments
0

From my reply at https://www.wireshark.org/lists/wireshark-users/202001/msg00000.html:

In your screenshot, the visible frames are:

1. C->S Protected Payload
2. S->C Handshake, PKN:0, CRYPTO
3. C->S Handshake, PKN:0, ACK, CRYPTO
4. S->C Handshake, PKN:1, ACK
5. C->S Protected Payload
...
11. S->C Protected Payload

The selected packet (frame 4) shows that draft 24 is in use. I would have expected an Initial Packet message to be present. Perhaps frame 1 has additional data.

Do frames 5-11 actually mention that decryption failed? If so, it should describe the reason. If you were expecting HTTP/3, note that it is still work in progress, and not supported in the current Wireshark 3.2 release nor the development version, v3.3.0rc0-225-g76dfe6004b.

For better analysis, please attach the original packet capture and the SSLKEYLOGFILE file. For the current state of QUIC support in Wireshark, please refer to https://github.com/quicwg/base-drafts/wiki/Tools#wireshark and find capture samples at https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13881

Lekensteyn's avatar
2.3k
Lekensteyn
answered 2020-01-03 13:55:49 +0000
edit flag offensive 0 remove flag delete link
more

Comments

add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer