[tor-relays] [Important] A call for more long running bridges, especially with OBFS IAT-Mode set to 1 or 2.

[George Hartley]

Hi,

even if the paper was from 2018, traffic confirmation attacks are still a problem on a real-time anonymity network.

Albert Einstein said that E equals mc², and that was in 1905.. does not make it any less true today!

The paper specifically recommends iat-mode = 1, or even better, 2, for protection.

I'd rather take the bandwidth penalty but have at least some protection against traffic correlation attacks.

That being said, I already use Whonix which comes with the Vanguard add-on pre-configured and enabled.

The author of obfs4 implemented this feature for a reason - if he thought it would be useless as a defense, he would not have wasted his time and written the code in the first place.

So yeah, a few bridges with iat-mode = 1 or 2 would be nice, for those who are extra paranoid, which you can kind of call me.

Cheers,
George 


------- Original Message -------
Fran via tor-relays <tor-relays at lists.torproject.org> schrieb am Montag, 15. Mai 2023 um 11:19 vorm.:


> Hey,
> 

> the paper is from August 2018 (if I looked at the correct one), not so
> recent :)
> 

> And e. g. Philipp Winter questions the usefulness of iat_mode:
> 

> > substantial performance penalty for a dubious and poorly understood
> 

> privacy gain
> 

> https://lists.torproject.org/pipermail/tor-relays/2021-February/019370.html
> 

> 

> I personally leave my bridges as they are, without iat_mode.
> 

> 

> Best,
> 

> Fran
> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> On 5/12/23 13:34, George Hartley via tor-relays wrote:
> 

> > Hello dear relay and bridge hosts,
> > 

> > recently a paper was published, describing a traffic confirmation attack
> > called DeepCorr, which works against Tor users and as such, also hidden
> > services.
> > 

> > The attack allegedly had success rates of up to 96% percent.
> > 

> > It is being worked on and listed here as a separate ticket:
> > 

> > https://forum.torproject.net/t/tor-dev-critical-deepcorr-traffic-confirmation-attack/6720 https://forum.torproject.net/t/tor-dev-critical-deepcorr-traffic-confirmation-attack/6720
> > 

> > Until mitigations have been merged into the Tor codebase, I kindly ask
> > you, the driving force behind the network, to set up more bridges with
> > "iat-mode" enabled and set to "1" or "2" - the paper stated that it was
> > significantly harder to launch successful attacks against clients using
> > OBFS4 bridges with timing obfuscation enabled, which is what "iat-mode"
> > really is.
> > 

> > In a nutshell, the measure of IAT is the average (or the arithmetic
> > mean) between network packets arriving at a host over a period of time,
> > of the times between packets arriving at a host over a period of time,
> > which you can also call latency.
> > 

> > For security reasons such as defeating DPI and similar network analysis
> > techniques, OBFS4, while at the same time encrypting and making your
> > traffic look like regular TLS traffic, it also
> > offers to try and obfuscate the IAT and packet size by inserting random
> > padding bytes.
> > 

> > For you guys or girls with programming skills or the ability to read and
> > understand code, here is the responsible code:
> > 

> > https://github.com/Yawning/obfs4/blob/40245c4a1cf221395c59d1f4bf274127045352f9/transports/obfs4/obfs4.go#L481 https://github.com/Yawning/obfs4/blob/40245c4a1cf221395c59d1f4bf274127045352f9/transports/obfs4/obfs4.go#L481
> > 

> > I vote for a fair 50 / 50 distribution of bridges with "iat-mode=1" and
> > "iat-mode=2", even though while IAT mode 2, also called the "paranoid"
> > mode by the author of the code above, may be more effective.
> > 

> > Dear clients, you can already enable timing-obfuscation in one way,
> > by editing your bridge-line and setting iat-mode from "0" to either "1"
> > or "2" - please be aware that this will only enable timing-obfuscation
> > in one way, the bridge needs to support it too to get packet timing
> > obfuscated in both ways.
> > 

> > Dear bridge operators, all it takes is a simple tor configuration file
> > change:
> > 

> > ServerTransportOptions obfs4 iat-mode=1
> > 

> > or
> > 

> > ServerTransportOptions obfs4 iat-mode=2
> > 

> > Your bridge key will very likely stay the same, although I /do not/ have
> > the infrastructure to try this out right now.
> > 

> > It is and has been very hard to find reliable OBFS4 bridges which
> > also support timing obfuscation, for over a year now - please consider
> > changing your bridge configuration in order to possibly help clients and
> > hidden services evade timing related attacks such as DeepCorr.
> > 

> > Yours truly,
> > George Hartley
> > 

> > _______________________________________________
> > tor-relays mailing list
> > tor-relays at lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 

> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-------------- 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/20230616/b02e5e44/attachment-0001.sig>