[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.net/t/tor-dev-critical-deepcorr-traffic-confirmatio... 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/40245c4a1cf221395c59d1f4bf274127045352... 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 :) 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-confirmatio... <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/40245c4a1cf221395c59d1f4bf274127045352... <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 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
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@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-confirmatio... https://forum.torproject.net/t/tor-dev-critical-deepcorr-traffic-confirmatio...
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/40245c4a1cf221395c59d1f4bf274127045352... https://github.com/Yawning/obfs4/blob/40245c4a1cf221395c59d1f4bf274127045352...
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 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
participants (2)
-
Fran -
George Hartley