Add handshake hooking capabilities

[theodorsm]

Description

This PR is part of a larger project adding anti-fingerprint features to make this library censorship-resistant, as it is used by Snowflake. The main features of this PR are the following:

• Added a workflow for automatically generating fresh DTLS handshakes (fingerprints) of new browser versions (Firefox and Chrome) by using a minimal webrtc example application and Selenium. The handshakes are captured and stored as pcap artifacts. The pcaps are further parsed and a fingerprint is added to pkg/mimicry/fingerprints.go.
• Mimick client hello messages by replaying fingerprints. This is enabled by a config flag and does not make any other API changes for users. Specific fingerprints can be chosen by a config flag or if it's empty, the most recent fingerprint will be chosen.
• Hooking of the client hello, server hello and certificate request messages.

Note:

• Enabling hooking might be unstable as a client/server might announce a cipher it actually does not support or because the internal state is not changed.
• The fingerprints are collected from a webrtc use case, the use_srtp extension is added to the handshake.

Reference issue

https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40014

Todos

• Documentation
• Examples
• Decide how often the fingerprint generation workflow should be run.
• Decide if pcaps should be committed to this repo or not.

[daenney]

I'm personally a fairly strong no on this change.

I don't mind taking on changes to make this library configurable enough that it can be used successfully to mimic a particular handshake. But taking on the burden of providing censorship resistance, keeping the fingerprints up to date and potentially dealing with any issues from it doesn't strike me as the right thing for the Pion community to spend its innovation tokens/budget on.

I'm curious to here how other maintainers feel about this.

[theodorsm]

Thanks for your input @daenney. I have talked with @Sean-Der about this, and he seems positive about the idea (at least the idea I have explained, the implementation might be different), but I do see your point in spending the innovation budget on this.

I am doing this as part of my master thesis on "Reducing distinguishability of DTLS for usage in Snowflake". The goal is to create something similar to uTLS for DTLS. An option is to fork the repo and add the features, trying to keep it up-to-date with Pion upstream as the anti-censorship team working on Snowflake wants the library they are using to be regularly updated of course.

Keeping the fingerprints up to date is taken care of by the added workflow and should not be something you as the maintainers should have to spend time on. The workflow as it is now auto-commits the fingerprints only after passing linting and E2E tests. Another possibility would be to just add the config/replay fingerprints feature and create a bot that auto-creates PRs for fresh fingerprints instead (or have a bring-your-own-fingerprints model) if you are concerned about the fingerprint generation workflow.

Mimicking will always be a bit unstable, but should not affect regular users of this library. The tradeoff has to be made clear and would be worth it for those who need fingerprint/censorship-resistance.

[theodorsm]

I have now moved the fingerprint generation workflow to its own repo. This PR now only consists of the mimicking and configuration features. A BYOF (bring your own fingerprints) approach will relieve pion maintainers from the burden of keeping fingerprints up to date and working. An example of how to use generated fingerprints can be found in pkg/mimicry/README.md.

[at-wat]

I second #631 (comment)

Supporting a general hook mechanism to allow adding such functionality would be fine, but I think the implementation of the hook should be out of this package unless it's standardized by RFC or it's a de-facto standard.

[theodorsm]

Thanks for the feedback @at-wat, @daenney. I have now reduced this PR to a simple and general hook of the client hello message and moved the implementation to a separate package. This also leaves room for implementing other anti-fingerprint features than mimicking without pushing upstream to pion.

I will write some docs on why this hooking feature is needed and how it could be used soon.

[codecov]

Codecov Report

Attention: Patch coverage is 96.84211% with 3 lines in your changes are missing coverage. Please review.

Project coverage is 79.98%. Comparing base (2c36d63) to head (4e7cfdc).

Files	Patch %	Lines
flight4bhandler.go	76.92%	1 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #631      +/-   ##
==========================================
+ Coverage   79.90%   79.98%   +0.07%     
==========================================
  Files         101      101              
  Lines        5286     5306      +20     
==========================================
+ Hits         4224     4244      +20     
+ Misses        689      687       -2     
- Partials      373      375       +2     

Flag	Coverage Δ
go	80.01% <96.84%> (+0.07%)	⬆️
wasm	63.85% <87.36%> (-0.10%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[theodorsm]

@daenney @at-wat @Sean-Der, this PR should be done now. My module covertDTLS provides fingerprints and the implementation of mimicking (I am also planning some other features). An example of usage can be found in the other repo's README.

[theodorsm]

I have also added hooks for the server hello and certificate request as the messages contain extensions or fields with lists which will be relevant to re-order for fingerprint-resistance.

[at-wat]

The hook API looks good to me!
Could you add a test for CertificateRequestMessageHook as well?

Also, please squash the intermediate commits before merge

[at-wat]

LGTM

[at-wat]

@daenney Any thoughts on the hook API?

[daenney]

Nothing really stands out to me, I think this makes sense 👍

[at-wat]

@theodorsm Thank you for your contribution! Merging now