Out of curiosity, can any other options be passed with ServerTransportOptions besides iat-mode?
I could only find this article saying there is a 'cert=' option, which initially appear useful for Tor. https://hamy.io/post/000d/how-to-hide-obfuscate-any-traffic-using-obfs4/ Thank you On Monday, September 23rd, 2024 at 6:15 AM, George Hartley via tor-relays - tor-relays at lists.torproject.org <tor-relays@lists.torproject.org> 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 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 > > > _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
