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@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > _______________________________________________ > tor-relays mailing list > tor-relays@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays