[Bug 94130] Re: HTTPS over proxy fails

[Chadwick Caraway]

<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:media="http://search.yahoo.com/mrss/">
<title>support issues</title>
<link href="/tpo/web/support/-/issues.atom?state=opened" rel="self" type="application/atom+xml"/>
<link href="https://gitlab.torproject.org/tpo/web/support/-/issues" rel="alternate" type="text/html"/>
<id>https://gitlab.torproject.org/tpo/web/support/-/issues</id>
<updated>2021-07-07T09:01:18Z</updated>
<entry>
  <id>https://gitlab.torproject.org/tpo/web/support/-/issues/237</id>
  <link href="https://gitlab.torproject.org/tpo/web/support/-/issues/237"/>
  <title>Add snowflake-client.exe to antivirus allowlist</title>
  <updated>2021-07-07T09:01:18Z</updated>
  <media:thumbnail width="40" height="40" url="https://gitlab.torproject.org/uploads/-/system/user/avatar/259/avatar.png"/>
  <author>
    <name>Gus</name>
    <email></email>
  </author>
  <summary>Add snowflake-client.exe to antivirus allowlist</summary>
  <description>Some users are reporting that their [Windows Defender](https://www.reddit.com/r/TOR/comments/of1gu3/windows_defender_latest_tor_browser_bundle/) is removing/messing up with their Tor Browser 10.5 because of `snowflake-client.exe`.

We should update our recommendations here:
https://support.torproject.org/tbb/tbb-10/</description>
  <content>Some users are reporting that their [Windows Defender](https://www.reddit.com/r/TOR/comments/of1gu3/windows_defender_latest_tor_browser_bundle/) is removing/messing up with their Tor Browser 10.5 because of `snowflake-client.exe`.

We should update our recommendations here:
https://support.torproject.org/tbb/tbb-10/</content>
  <milestone>Tor Browser: 10.5</milestone>
  <labels>
    <label>Documentation</label>
  </labels>
</entry>
<entry>
  <id>https://gitlab.torproject.org/tpo/web/support/-/issues/232</id>
  <link href="https://gitlab.torproject.org/tpo/web/support/-/issues/232"/>
  <title>Add &quot;You should send padding so it&#39;s more secure.&quot;</title>
  <updated>2021-06-17T21:49:20Z</updated>
  <media:thumbnail width="40" height="40" url="https://gitlab.torproject.org/uploads/-/system/user/avatar/259/avatar.png"/>
  <author>
    <name>Gus</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://2019.www.torproject.org/docs/faq.html.en#SendPadding</description>
  <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

** Bug watch added: gitlab.torproject.org/tpo/web/support/-/issues #237
   https://gitlab.torproject.org/tpo/web/support/-/issues/237

** Bug watch added: gitlab.torproject.org/tpo/web/support/-/issues #232
   https://gitlab.torproject.org/tpo/web/support/-/issues/232

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/94130

Title:
  HTTPS over proxy fails

Status in Awn-Py-Applets:
  Incomplete
Status in Python:
  Fix Released
Status in Ubuntu One Client:
  Invalid
Status in apport package in Ubuntu:
  Fix Released
Status in python2.6 package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: apport

  My network is behind a proxy.
  I ran "ubuntu-bug -p desktop-effects" and I received a "no route to host" error.
  The app should try to use the gnome proxy or at least fail notifying the user that he/she might be behind a proxy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/awn-py-applets/+bug/94130/+subscriptions