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:
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
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
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=1This 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=2For 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
On Montag, 23. September 2024 22:27:25 CEST Fran via tor-relays wrote:
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.
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
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.
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.
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. ;-)
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:
On 9/24/24 15:40, boldsuck via tor-relays wrote:
https://paste.systemli.org/?d3987a7dc4df49fa#7GF2qk8hyTVgkinZshff9Dc9R6ukD DZo6BQqwQURzjQy
OT, but useless use of cat ;)
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. :-)
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
Tor’s currently-deployed pluggable transports, showing that meek and obfs4-iat0 provide little protection against DeepCorr’s flow correlation, while obfs4-iat1 provides a better protection against DeepCorr (note that none of these obfuscation mechanisms are currently deployed by public Tor relays, and even obfs4-iat1 is deployed by a small fraction of Tor bridges [ 52]).
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:
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.
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
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.
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.
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!_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays@lists.torproject.org
-
boldsuck -
Fran -
George Hartley -
pasture_clubbed242＠simplelogin.com -
Toralf Förster