© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://
<title>support issues</title>
<link href="/
<link href="https:/
<id>https:/
<updated>
<entry>
<id>https:/
<link href="https:/
<title>Add snowflake-
<updated>
<media:thumbnail width="40" height="40" url="https:/
<author>
<name>
<email></email>
</author>
<summary>Add snowflake-
<description>Some users are reporting that their [Windows Defender](https:/
We should update our recommendations here:
https:/
<content>Some users are reporting that their [Windows Defender](https:/
We should update our recommendations here:
https:/
<milestone>Tor Browser: 10.5</milestone>
<labels>
<label>
</labels>
</entry>
<entry>
<id>https:/
<link href="https:/
<title>Add &quot;You should send padding so it&#39;s more secure.
<updated>
<media:thumbnail width="40" height="40" url="https:/
<author>
<name>
<email></email>
</author>
<summary>Add "You should send padding so it's more secure."</summary>
<description>We have some new proposals and discussion, we should update this answer:
Like all anonymous communication networks that are fast enough for web browsing, Tor is vulnerable to statistical "traffic confirmation" attacks, where the adversary watches traffic at both ends of a circuit and confirms their guess that those endpoints are communicating. It would be really nice if we could use cover traffic to confuse this attack. But there are three problems here:
Cover traffic is really expensive. And *every* user needs to be doing it. This adds up to a lot of extra bandwidth cost for our volunteer operators, and they're already pushed to the limit.
You'd need to always be sending traffic, meaning you'd need to always be online. Otherwise, you'd need to be sending end-to-end cover traffic -- not just to the first hop, but all the way to your final destination -- to prevent the adversary from correlating presence of traffic at the destination to times when you're online. What does it mean to send cover traffic to -- and from -- a web server? That is not supported in most protocols.
Even if you *could* send full end-to-end padding between all users and all destinations all the time, you're *still* vulnerable to active attacks that block the padding for a short time at one end and look for patterns later in the path.
In short, for a system like Tor that aims to be fast, we don't see any use for padding, and it would definitely be a serious usability problem. We hope that one day somebody will prove us wrong, but we are not optimistic.
We did however since implement netflow padding to collapse netflow records for improved security. Now padding is sent between a client's Tor connection and its guard bidirectionally at a random interval that we control from the consensus, with a default of 4 to 14 seconds if the connection is idle. This has the goal of stymying some of the potential traffic analysis attacks out there -- website fingerprinting, end-to-end correlation, and the things in between.
For details see the blog post by the Tor network team, the announcement on the tor-dev mailinglist or read further publications on padding.
https:/
<content>We have some new proposals and discussion, we should update this answer:
Like all anonymous communication networks that are fast enough for web browsing, Tor is vulnerable to statistical "traffic confirmation" attacks, where the adversary watches traffic at both ends of a circuit and confirms their guess that those endpoints are communicating. It would be really nice if we could use cover traffic