How to decrypt the quic protected payload?

[xieyuschen]

As the quic uses the TLSv1.3 to encrypt packets, many packets are encrypted which needs to decrypt when we are trying the quic protocol. The way to decrypt the packets by wireshark is shown below:

1. Obtain the session
   We should first obtain the session Id from TLS. It could be specified as output log file to debug in the TLS config file. In golang, could set the tls.Config struct to get the session. The other language also provides such interface such as RUST provide a way by specify the variable SSLKEYLOGFILE. Note: Check whether the log file is completed like this, if it's not completed the decryption in wireshark fails of course.

   CLIENT_HANDSHAKE_TRAFFIC_SECRET 4a91b2801514....blabla
   SERVER_HANDSHAKE_TRAFFIC_SECRET 4a91b280151....blabla
   CLIENT_TRAFFIC_SECRET_0 4a91b28015147bb400e48....blabla
   SERVER_TRAFFIC_SECRET_0 4a91b28015147bb400e48....blabla

2. Load it to wireshark cloudfare quiche issue has discussed this one, should upgrade wireshark which supports QUIC draft-29. Here is a reference about wireshark tools. If you use ubuntu, can upgrade wireshark:

   sudo add-apt-repository ppa:wireshark-dev/stable
   sudo apt-get update
   sudo apt-get install wireshark

   Edit->Protocol->TLS->(Pre)-Master-Secret log filename. I use the latest version as v3.6.5 and it works well.

[chilicomputer]

I used wireshark v4.0.0 but still encountered the problem : And my SSLKEYLOGFILE looks like this: I googled and found this issue, so what can i do now?

[xieyuschen]

Hi @chilicomputer , based on your screenshot, here is my analysis and hope it can help you.

• your wireshark might no problems. As it already shows quic in its protocol field, so I think it's not caused by the version of wireshark.

• the SSL key log file. You need to make sure that your SSL key log file is corresponding to the handshake. I mean after you create the quick connection between client and server, you get the SSL key session. Remember that this session only can be used in your current wireshark packet record, which means if you run the client twice to create a new quic connection but use the old session, the decryption will fail.

So for your problem, you just need to record the packets after creating a quic connection between client and server, (save them), import the SSL key log , and finally you can see the details of the packets.

[chilicomputer]

Well, it seems ok now:)

Thanks!

[cslev]

I am also playing around with QUIC and I was always able to do everything you mentioned. My problem now is that, probably due to the QUIC's "multistream" nature, I don't really see any meaningful HTTP3 messages. Just like in your case, wireshark can decrypt QUIC and you can see the Protected Payload and you even see that HTTP HEADERS are there. However, unlike TCP/TLS/HTTP2, where you can actually see that data in Wireshark, in HTTP3 you don't see the header data.

I realized that it actually requires Wireshark v4+ and the QUIC+QPACK library, which is libnghttp3. So you have to install that too if you want to decode the HTTP3 messages properly