Dear OBFS4 bridge operators, please enable timing and packet-size obfuscations to help clients facing timing analysis attacks.
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
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:
pasture_clubbed242--- via tor-relays wrote:
I could only find this article saying there is a 'cert=' option, which initially appear useful for Tor.
Cert is default in obfs4 bridelines, you can create yours with: ~# cat /var/lib/tor-instances/01/fingerprint nikname fingerprint ~# cat /var/lib/tor-instances/01/pt_state/obfs4_bridgeline.txt # obfs4 torrc client bridge line # # This file is an automatically generated bridge line based on # the current obfs4proxy configuration. EDITING IT WILL HAVE # NO EFFECT. # # Before distributing this Bridge, edit the placeholder fields # to contain the actual values: # <IP ADDRESS> - The public IP address of your obfs4 bridge. # <PORT> - The TCP/IP port of your obfs4 bridge. # <FINGERPRINT> - The bridge's fingerprint. Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=glib+gliberish+gliberish iat-mode=0 -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!
Philipp Winter regarding iat mode:
https://lists.torproject.org/pipermail/tor-relays/2021-February/019370.html On 23/09/2024 12:15, George Hartley via tor-relays wrote:
On Montag, 23. September 2024 22:27:25 CEST Fran via tor-relays wrote:
Yes, I was also wondering if any new research papers have appeared on this topic. In recent years, Roger and the other Tor Dev's have advised against using !=(iat-mode=0) If obfs4/Lyrebird iat-mode=0 is not effective, then all bridges in China and Russia should be blocked within a few days. My bridge stats don't confirm that: https://paste.systemli.org/?d3987a7dc4df49fa#7GF2qk8hyTVgkinZshff9Dc9R6ukDDZ... If anything has changed, we should put it on the agenda at the next meetup. And official instructions on what clients should configure and what servers should configure. Not official yet, I've been hiding the OrPort for bridges for a year now. https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/129
But traffic analysis for guard discovery attack has nothing to do with traffic analysis to detect Tor traffic.
If your bridge is distributed by BridgeDB Rdsys, BridgeDB is gone. ;-)
-- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!
On 9/24/24 15:40, boldsuck via tor-relays wrote:
https://paste.systemli.org/?d3987a7dc4df49fa#7GF2qk8hyTVgkinZshff9Dc9R6ukDDZ... OT, but useless use of cat ;)
-- Toralf
Toralf Förster via tor-relays wrote:
Oh, you're right. It's nicer because I have instance name in front of it. grep bridge-ips /var/lib/tor-instances/*/stats/bridge-stats /var/lib/tor-instances/45/stats/bridge-stats:bridge-ips I still prefer to use cat for public pastebin. Less information is better. :-) -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!
There are new research papers available, suggesting that iat-mode being not set to the default value of 0 resulting in better protection against flow correlation / timing analysis. Here is a recent one that I did not read much into yet: https://arxiv.org/pdf/1808.07285
This is just one paper using one machine learning model, but there are others and it is 7AM, so I have to get some sleep before I go to work. Regards, George On Tuesday, September 24th, 2024 at 3:40 PM, boldsuck via tor-relays tor-relays@lists.torproject.org wrote:
On Montag, 23. September 2024 22:27:25 CEST Fran via tor-relays wrote:
Philipp Winter regarding iat mode:
Not official yet, I've been hiding the OrPort for bridges for a year now. https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/129
On 23/09/2024 12:15, George Hartley via tor-relays wrote:
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.
But traffic analysis for guard discovery attack has nothing to do with traffic analysis to detect Tor traffic.
If your bridge is distributed by BridgeDB
Rdsys, BridgeDB is gone. ;-)
-- ╰_╯ Ciao Marco!
Debian GNU/Linux
participants (5)
-
boldsuck -
Fran -
George Hartley -
pasture_clubbed242＠simplelogin.com -
Toralf Förster