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

[George Hartley]

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 at 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#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!_______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20240925/f6743d94/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - hartley_george at proton.me - 0xAEE8E00F.asc
Type: application/pgp-keys
Size: 657 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20240925/f6743d94/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20240925/f6743d94/attachment-0001.sig>