Philipp Winter regarding iat mode:
>The feature introduces a substantial performance penalty for a dubious
>and poorly understood privacy gain. If I were to write an algorithm to
>detect obfs4, I wouldn't bother dealing with its flow properties; there
>are easier ways to identify the protocol. In hindsight, it was >probably
>a mistake to expose the iat option to users and bridge operators.
>
>Cheers,
>Philipp
https://lists.torproject.org/pipermail/tor-relays/2021-February/019370.html
On 23/09/2024 12:15, George Hartley via tor-relays wrote:
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 andround 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
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
