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. ;-)