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
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
> tor-dev Info Page
>
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
tor-dev Info Page
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev