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

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.org/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

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

Hey,

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

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:

[tor-dev] [CRITICAL] DeepCorr Traffic Confirmation Attack

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

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@lists.torproject.org
tor-relays Info Page

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