[CRITICAL] DeepCorr Traffic Confirmation Attack
Hi, I was just reading a paper on traffic confirmation attacks over here https://arxiv.org/pdf/1808.07285v1.pdf. This attack runs with the help of deep learning algorithm called DeepCorr. This attack can be run in a Five Eyes country or an authoritarian regime like Russia where companies are compelled to cooperate with the government making this attack plausible. The ISP and the website operators are the two endpoints for this attack. This attack was able to achieve a success rate of over 96% which represents a serious threat to Tor users in these regions. The paper also includes some countermeasures on how to defeat this method of traffic confirmation. Thanks.
This attack looks especially bad for situations where both ends of the connection are controlled by the attacker, so it seems really bad for onionshare, ricochet refresh, Briar, and Quiet, at least when users are communicating with others in the same country. 96% correlation after 900k of data sent! That's just a few images or files. It probably would work again cwtch too at least if it was trained for that, since while users might be connected to a server outside the attacker's region of control, but the data flows would correlate since the cwtch server is also just relaying data. Should all of these apps be using obs4 with IAT mode on? (The mitigation recommended by the paper?) How meaningful is Tor's metadata protection for an app like Quiet, Briar, or OnionShare given this attack, assuming most users are communicating with others within a country that can mount such an attack? On Tue, Feb 28, 2023, 8:23 AM Guard via tor-dev < tor-dev@lists.torproject.org> wrote:
Hi,
I was just reading a paper on traffic confirmation attacks over here https://arxiv.org/pdf/1808.07285v1.pdf. This attack runs with the help of deep learning algorithm called DeepCorr. This attack can be run in a Five Eyes country or an authoritarian regime like Russia where companies are compelled to cooperate with the government making this attack plausible. The ISP and the website operators are the two endpoints for this attack. This attack was able to achieve a success rate of over 96% which represents a serious threat to Tor users in these regions. The paper also includes some countermeasures on how to defeat this method of traffic confirmation.
Thanks.
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
I have not read this paper thoroughly, and it definitely seems to make a significant contribution. But the concerns that you raise are not what is new, and I hope this message will reduce your sense of alarm. If an attacker is interested in a given user or onion service and can watch both ends of a connection, it is well documented that they can correlate with high accuracy and low false positives. And this was understood, if not yet experimentally validated, not just when we first made Tor, but for pre-Tor versions of onion routing. The issue discussed in the paper is to be able to look at (both ends of) _large volumes_ of traffic flow and be able do correlations with low false positives. I haven't had a chance to look carefully at the contribution, but even in this area the novelty is somewhat overstated, because IMO the authors understate the contributions of their reference [49]. Murdoch and Zielinski showed back in 02007 that an IXP could correlate quite well sampling only around 1/2000 packets. Somebody should idiot-check me, since I'm pulling those results from memory without looking (too busy today). Nonetheless, even if the numbers aren't exactly right, Murdoch and Zielinksi showed the ability to correlate at scale with low sampling. Again, I believe the paper being discussed substantially improves on [49] in many respects, but the basic idea that correlation at scale is feasible was not only understood but demonstrated sixteen years ago. HTH. On Tue, Feb 28, 2023 at 09:59:00AM -0300, Holmes Wilson wrote:
This attack looks especially bad for situations where both ends of the connection are controlled by the attacker, so it seems really bad for onionshare, ricochet refresh, Briar, and Quiet, at least when users are communicating with others in the same country. 96% correlation after 900k of data sent! That's just a few images or files.
It probably would work again cwtch too at least if it was trained for that, since while users might be connected to a server outside the attacker's region of control, but the data flows would correlate since the cwtch server is also just relaying data.
Should all of these apps be using obs4 with IAT mode on? (The mitigation recommended by the paper?)
How meaningful is Tor's metadata protection for an app like Quiet, Briar, or OnionShare given this attack, assuming most users are communicating with others within a country that can mount such an attack?
On Tue, Feb 28, 2023, 8:23 AM Guard via tor-dev < tor-dev@lists.torproject.org> wrote:
Hi,
I was just reading a paper on traffic confirmation attacks over here https://arxiv.org/pdf/1808.07285v1.pdf. This attack runs with the help of deep learning algorithm called DeepCorr. This attack can be run in a Five Eyes country or an authoritarian regime like Russia where companies are compelled to cooperate with the government making this attack plausible. The ISP and the website operators are the two endpoints for this attack. This attack was able to achieve a success rate of over 96% which represents a serious threat to Tor users in these regions. The paper also includes some countermeasures on how to defeat this method of traffic confirmation.
Thanks.
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
participants (3)
-
Holmes Wilson -
silentguard＠dnmx.org -
Syverson, Paul F CIV USN NRL (5543) Washington DC (USA)