Add TLSMirror Sequence Watermarking #3446
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request adds sequence watermarking support to TLSMirror.
Following some discussion with Fangliding(https://t.me/v2fly_chat/366660), I begin working on adding sequence watermarking on TLSMirror.
I already explained how it works, which I quote:
After the first encrypted frame is inserted, the last 16 bytes of encrypted data in each subsequent encrypted TLS frame will be re-encrypted in place based on the sender's sequence number. On the receiving end, the data will first be decrypted in place using the receiver's sequence number before attempting to decrypt or forward it to the original connection. If the sequence number is incorrect, decryption will fail both at the TLSMirror end and at the remote end, and then the remote end will handle it according to the normal TLS error handling process (this error cannot be detected at the TLSMirror, but that's fine because letting the forwarding end handle the error actually makes more senses when it comes to anti-censorship purpose).
If a packet get delivered out of order(no matter it is produced by an real tls implementation (real client or forwarded site) or TLSMirror, then its authentication tag would be invalided by sequence watermarking, by XOR it will 2 different watermark key material, thus can't be decrypted by either TLSMirror (at which point get forwarded to forwarded site) or the forwarded site, and get a error response from forwarded site.
If a packet is delivered in order, then it get XORed with the same watermarking key material twice, and restoring it to the original state.