Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
  • Sign in / Register
wireshark
wireshark
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 1,305
    • Issues 1,305
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 83
    • Merge Requests 83
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Wireshark Foundation
  • wiresharkwireshark
  • Issues
  • #17011

Closed
Open
Opened Nov 13, 2020 by Ivan Nardi@IvanNardiContributor

QUIC: missing dissection of some coalesced SH packets

Summary

Current code is not able to dissect, let alone decrypt, some coalesced Short Header packets

Steps to reproduce

Open the pcap attached in #17010 (closed) and look at packet 7: the LH packet is correctly dissected/decrypted, the SH one is not.

Note that this issue seems to be completely unrelated to #17010 (closed): it simply happens that the same pcap triggers two different bugs.

In general, to trigger this issue you must have:

  • a coalesced Short Header packet
  • the -encrypted- first byte of this packet must be 0x00. Note that this can happen only when the QUIC bit has been greased.

The root cause is the workaround added to handle Firefox neqo behavior, which adds unencrypted padding consisting of all zeroes after an Initial Packet (see a2368cd1 and 43e0bd12).

Even if the effects are different, this issue and #16914 (closed) share the same problem (and same solution maybe?): we should do a better job handling (random) padding.

What is the current bug behavior?

(What actually happens)

What is the expected correct behavior?

Full dissection/decryption

Sample capture file

See #17010 (closed)

Relevant logs and/or screenshots

(Paste any relevant logs)

Build information

3.5.0 (v3.5.0rc0-116-g580de0984981)

Compiled (64-bit) with Qt 5.9.5, with libpcap, with POSIX capabilities (Linux),
with libnl 3, with GLib 2.56.4, with zlib 1.2.11, with SMI 0.4.8, with c-ares
1.14.0, with Lua 5.2.4, with GnuTLS 3.5.18 and PKCS #11 support, with Gcrypt
1.8.1, with MIT Kerberos, with MaxMind DB resolver, with nghttp2 1.30.0, with
brotli, with LZ4, with Zstandard, with Snappy, with libxml2 2.9.4, with
QtMultimedia, without automatic updates, with SpeexDSP (using system library).

Running on Linux 4.15.0-123-generic, with Intel(R) Core(TM) i7-4810MQ CPU @
2.80GHz (with SSE4.2), with 15944 MB of physical memory, with locale
LC_CTYPE=en_US.UTF-8, LC_NUMERIC=it_IT.UTF-8, LC_TIME=it_IT.UTF-8,
LC_COLLATE=en_US.UTF-8, LC_MONETARY=it_IT.UTF-8, LC_MESSAGES=en_US.UTF-8,
LC_PAPER=it_IT.UTF-8, LC_NAME=it_IT.UTF-8, LC_ADDRESS=it_IT.UTF-8,
LC_TELEPHONE=it_IT.UTF-8, LC_MEASUREMENT=it_IT.UTF-8,
LC_IDENTIFICATION=it_IT.UTF-8, with light display mode, without HiDPI, with
libpcap version 1.8.1, with GnuTLS 3.5.18, with Gcrypt 1.8.1, with brotli 1.0.4,
with zlib 1.2.11, binary plugins supported (18 loaded).

Built using gcc 8.4.0.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: wireshark/wireshark#17011