Observing QUIC packets generated by Chrome seems to show that a fuzzing/greasing approach is used their Initial packets, presumingly for the good reasons of having implementors follow QUIC specification correctly. Often, with some level of randomness, I've seen the initial packets filled with multiple PADDING and PING frames, as well as the fragmentation and reordering of CRYPTO frames.
It seems that in some of these cases Wireshark isn't able to reassemble the Client Hello correctly, resulting in Wireshark not being able to decrypt the TLS session (with a valid TLS key), and that interfers with packet analysis work. So I thought that if I'm able to rewrite the initial QUIC packet with the excessive greasing, perhaps Wireshark would be able to decode them fine.
Fortunately, AWS's QUIC library s2n-quic provides some APIs in Rust to help with QUIC packet parsing, decryption and encryption. I was able to quickly put together something that extracts the ClientHello / crypto frame out of a Quic packet and then serialize a new QUIC packet without the fragmentation.
Sample usage
$ quic-initial-degreaser test.pcap out.pcap
Input: test.pcap
Output: out.pcap
Initial QUIC Packets rewritten: 1
Total entries written: 22
-
Before
-
After
quic_initial_degreaser::degrease_initial_packet(bytes)
returns a new vector of bytes if it can decode an initial QUIC payload.
extract_initial_packet() and generate_initial_packet() can be used if you want to extract or bring your own ClientHello in the initial packet