[Peter Wu <peter@xxxxxxxxxxxxx>]

Hi Magesh,

On Wed, Dec 25, 2019 at 01:43:48PM +0530, Magesh Dhasayyan wrote:
> Hi,
> 
> 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. opened 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: https://ibb.co/ysgN5yW

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

For future reference, this is a repost of
https://ask.wireshark.org/question/13818/ws-320-quic-handshake-is-decrypted-but-subsequent-packets-are-not/
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl