[tor-relays] Dear OBFS4 bridge operators, please enable timing and packet-size obfuscations to help clients facing timing analysis attacks.

[boldsuck]

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#7GF2qk8hyTVgkinZshff9Dc9R6ukDDZo6BQqwQURzjQy

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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 3872 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20240924/7a7d2f86/attachment.sig>