Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

QUIC Initial Packet Decryption and Parsing #55

Merged
merged 1 commit into from
Sep 7, 2024

Conversation

sippejw
Copy link
Contributor

@sippejw sippejw commented Sep 6, 2024

Same as PR #37, updates being that rust-crypto has been replaced with aes-gcm.

Summary

The standard QUIC handshake between two hosts who do not have a pre shared key involves the use of QUIC Initial packets to share a TLS 1.3 client and server hello. After these two messages have been received, the hosts are able to change to new keys unknown to network observers. This PR add the ability to parse QUIC Initial packets, decrypt the protected payloads, parse the QUIC frames, and parse the TLS client and server hello. This gives users the ability to filter QUIC traffic on many of the same features as TLS, such as SNI.

Features

  • Fixes bug that causes subtraction overflow panic on short retry packets
  • Adds module (crypto.rs) for initial key derivation, based on Cloudflare's Quiche
  • Decrypts all init packets
  • Parses QUIC frames through new module frame.rs
  • Introduces QuicConn for tracking multi-packet QUIC connections
  • Handles CRYPTO frame reassembly, necessary for Chrome
  • Parses TLS Client and ServerHello, stored in a field on the QuicConn object
  • Adds buffers for multi packet ClientHello and ServerHello TLS messages, necessary for connections negotiating a Kyber key

Testing

  • Adds two new traces quic_kyber.pcapng and quic_xargs.pcap for testing QUIC parsing
  • Additionally testing on all preexisting pcaps in traces/
  • 5 minutes on network:
Port 0 statistics
SW Capture %: UNKNOWN
Out of Buffer %: UNKNOWN
HW Discard %: UNKNOWN
+---------------+---------------------------+
|    1861289177 | rx_good_packets           |
| 1905023242622 | rx_good_bytes             |
|             0 | rx_missed_errors          |
|             0 | rx_mbuf_allocation_errors |
+---------------+---------------------------+
----------------------------------------------
Current time: 299s
mempool_0 avail: 8356114, in use: 32493 (0.387%)
Ingress: 0 bps / 0 pps
Good:    53482769216 bps / 6310938 pps
Process: 53482769216 bps / 6310938 pps
Drop: 0 pps (NaN%)
HW Dropped: 0 pkts (NaN%)
SW Dropped: 0 pkts (NaN%)
Total Dropped: 0 pkts (NaN%)
----------------------------------------------
AVERAGE Ingress: 0.000 bps / 0.000 pps
AVERAGE Good:    52340783432.752 bps / 6245936.836 pps
AVERAGE Process: 52340783432.752 bps / 6245936.836 pps
DROPPED: 0 pkts (NaN%)

Main done. Ran for 300.100800357s
Done. Logged 320839 Quic stream to "quic.jsonl"

@sippejw
Copy link
Contributor Author

sippejw commented Sep 6, 2024

Hey @thearossman, the commit in this PR removes the dependency that was causing build issues on ARM and will hopefully resolve the problem. If you can test on your ARM instances and let me know that would be greatly appreciated.

Additionally, it looks like it might take some git magic to fix the commit tree. Let me know if you need me to do anything on my end to get this resolved and checked in. Thanks!

@sippejw sippejw mentioned this pull request Sep 6, 2024
@thearossman
Copy link
Collaborator

sorry - looks like i gave you a couple of merge conflicts (which were trivial). just fixed.

@thearossman thearossman merged commit c3e1885 into stanford-esrg:main Sep 7, 2024
2 checks passed
@sippejw
Copy link
Contributor Author

sippejw commented Sep 7, 2024

Hey @thearossman, I believe the git tree is still a little messed up. It is missing the initial QUIC commits. Would it be possible to revert #41? Otherwise, I can try to recommit those contributions but that may get messy.

@thearossman
Copy link
Collaborator

yikes, thanks for noting that @sippejw . i can't revert #41 automatically, but I could revert this PR that I merged, which could presumably be rebased. would that help?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants