Hello Tor community, this e-mail applies to you if you are running an obfs4 (now known under the name lyrebird) bridge or want to do so in the future.
Some recent posts on this list has shown that traffic timing analysis can be
used to locate a users or onion services guard nodes or bridges. This is not
really something new.
For bridge users, there is a way to try to protect themselves against this, but
your bridge configuration must support it.
By enabling iat-mode on your obfs4 /lyrebird bridge, then maybe DPI (Deep
Packet Inspection) hardware can sometimes be defeated either entirely, or at
least the process of tracking users can be slowed down.
OBFS4/Lyrebird support two times of traffic obfuscation:
> ServerTransportOptions obfs4 iat-mode=1
This will make your bridge send MTU sized packets, in order to make
true packet size analysis harder.
There is also what the author of obfs4/Lyrebird called "paranoid mode":
> ServerTransportOptions obfs4 iat-mode=2
For each write, a variable length packet will be sent, which will result
in both making true packet size and round trip time analysis harder.
If your bridge is distributed by BridgeDB, the next time someone receives
a batch of bridges with your bridge in it, the bridge-line will have the
iat-mode variable set to the one
you set on your bridge server.
Your bridge will still work even if you enable these defenses and a user chooses
to set iat-mode to 0 in his bridge line.
There is a small performance penalty for both mode 1 and 2, but nothing very
severe.
I believe this, along with Vanguards, and so on, is needed to keep users and
services somewhat secure.
Let me know what you think.
- George
publickey - hartley_george@proton.me - 0xAEE8E00F.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
