The pitfall of using tshark to analyse QUIC protocol

Check the wireshark’s QUIC related code, we will find it heavily depends on 2 macros:

#ifdef HAVE_LIBGCRYPT_AEAD
......
#endif

#ifdef HAVE_LIBGCRYPT_CHACHA20
......
#endif

And these 2 macros rely on the version of libgcrypt (refer here):

/*
 * Define HAVE_LIBGCRYPT_AEAD here, because it's used in several source
 * files.
 */
#if GCRYPT_VERSION_NUMBER >= 0x010600 /* 1.6.0 */
/* Whether to provide support for authentication in addition to decryption. */
#define HAVE_LIBGCRYPT_AEAD
#endif

/*
 * Define some other "do we have?" items as well.
 */
#if GCRYPT_VERSION_NUMBER >= 0x010700 /* 1.7.0 */
/* Whether ChaCh20 PNE can be supported. */
#define HAVE_LIBGCRYPT_CHACHA20
/* Whether AEAD_CHACHA20_POLY1305 can be supported. */
#define HAVE_LIBGCRYPT_CHACHA20_POLY1305
#endif

On CentOS 7, the libgcrypt version is 1.5.3, so the above 2 macros will not be defined, and some functions are not available. While on CentOS 8, the libgcrypt version is 1.8.5, so the functions are fully supported. I met an issue, i.e., for the same pcap file, tshark (I built myself) on CentOS 7 assumes there is an error in decrypting QUIC flow:

$ /home/nanxiao/wireshark/build/run/tshark -nr 435.pcap -Y '(quic.decryption_failed)'
    1   0.000000 172.27.232.168 → 216.183.220.159 GTP <QUIC> 1310 Initial, DCID=68a3ee8706f87817

while tshark on CentOS 8 works OK:

$ /home/nanxiao/wireshark/build/run/tshark -nr 435.pcap -Y '(quic.decryption_failed)'
$

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.