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

[Fran]

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