Re: [tor-talk] atlas.torproject.org problems

2017-05-22 Thread nusenu
> Does https://atlas.torproject.org/ work very poorly for anyone else?
> Half of the time it fails to find any information about the requested relay 
> (by
> fingerprint), after some reloads it works. Searches also often fail with 
> "Atlas
> is unable to get a response from its backend server."

The backend is overloaded, see also:
https://lists.torproject.org/pipermail/tor-dev/2017-May/012262.html

> Also, there was another instance (mirror) of this service, anyone remembers 
> the
> URL?

The mirror (thecthulhu) no longer exists.


-- 
https://mastodon.social/@nusenu
https://twitter.com/nusenu_



signature.asc
Description: OpenPGP digital signature
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk


Re: [tor-talk] Use of TBB behind a physically isolated Tor router?

2017-05-22 Thread Lolint
> Even with software isolation though I am beginning to think that hardware 
> isolation
when implemented properly is more secure than software isolation, with all the 
Xen
bugs recently.

The Qubes OS team are going to ditch paravirtualization for hardware-based 
virtualization
since all the fatal Xen bugs that affected Qubes have been in mechanisms for 
handling
memory virtualization for paravirtualized (PV) VMs.

> Is there any comments on the way Whonix gateway and TBB work together?

In the Whonix workstation they use this package to prevent Tor over Tor with 
the TBB,

https://github.com/Whonix/anon-ws-disable-stacked-tor

Its implementation is well documented here,

https://www.whonix.org/wiki/Dev/anon-ws-disable-stacked-tor#Why.3F
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk


Re: [tor-talk] Other Metrics events

2017-05-22 Thread David Fifield
On Fri, May 19, 2017 at 03:12:34PM -0400, Lolint wrote:
> Nice find! To mention other events, something strange is happening in Taiwan,
> 
> https://metrics.torproject.org/userstats-relay-country.html?graph=userstats-relay-country&country=tw&events=on
> 
> And it looks like Egypt is starting to censor vanilla Tor again (election 
> times?),
> https://metrics.torproject.org/userstats-relay-country.html?graph=userstats-relay-country&country=eg&events=on
> 
> There does not appear to be a corresponding _significant_ increase in bridge 
> users,
> 
> https://metrics.torproject.org/userstats-bridge-combined.html?start=2017-02-18&end=2017-05-19&country=eg
> 
> A temporary sudden peak of direct users in Macau
> 
> https://metrics.torproject.org/userstats-relay-country.html?graph=userstats-relay-country&country=mo&events=on

Good finds. Could you add these events to the wiki page of metrics
events? You can put them under "Unknown" at the bottom.
https://trac.torproject.org/projects/tor/wiki/doc/MetricsTimeline

To edit a page you need to create an account
https://trac.torproject.org/projects/tor/register and then click the
Edit button at the bottom of the page.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk


[tor-talk] Tor 0.3.1.1-alpha is released!

2017-05-22 Thread Nick Mathewson
(Also, 0.3.0.7 was released last week.  If you didn't know, you should
subscribe to tor-announcements.)

Hi, all!

You can find the source code for Tor 0.3.0.1-alpha  www.torrpoject.org
at the usual place.  It's an alpha, so please expect plenty of bugs,
and be ready to report them.  Packages should be out over the next
weeks -- I'd expect this series to hit Tor Browser alpha releases some
time in the middle of June.
===

Changes in version 0.3.1.1-alpha - 2017-05-22
  Tor 0.3.1.1-alpha is the first release in the 0.3.1.x series. It
  reduces the bandwidth usage for Tor's directory protocol, adds some
  basic padding to resist netflow-based traffic analysis and to serve as
  the basis of other padding in the future, and adds rust support to the
  build system.

  It also contains numerous other small features and improvements to
  security, correctness, and performance.

  Below are the changes since 0.3.0.7.

  o Major features (directory protocol):
- Tor relays and authorities can now serve clients an abbreviated
  version of the consensus document, containing only the changes
  since an older consensus document that the client holds. Clients
  now request these documents when available. When both client and
  server use this new protocol, they will use far less bandwidth (up
  to 94% less) to keep the client's consensus up-to-date. Implements
  proposal 140; closes ticket 13339. Based on work by Daniel Martí.
- Tor can now compress directory traffic with lzma or with zstd
  compression algorithms, which can deliver better bandwidth
  performance. Because lzma is computationally expensive, it's only
  used for documents that can be compressed once and served many
  times. Support for these algorithms requires that tor is built
  with the libzstd and/or liblzma libraries available. Implements
  proposal 278; closes ticket 21662.
- Relays now perform the more expensive compression operations, and
  consensus diff generation, in worker threads. This separation
  avoids delaying the main thread when a new consensus arrives.

  o Major features (experimental):
- Tor can now build modules written in Rust. To turn this on, pass
  the "--enable-rust" flag to the configure script. It's not time to
  get excited yet: currently, there is no actual Rust functionality
  beyond some simple glue code, and a notice at startup to tell you
  that Rust is running. Still, we hope that programmers and
  packagers will try building Tor with Rust support, so that we can
  find issues and solve portability problems. Closes ticket 22106.

  o Major features (traffic analysis resistance):
- Connections between clients and relays now send a padding cell in
  each direction every 1.5 to 9.5 seconds (tunable via consensus
  parameters). This padding will not resist specialized
  eavesdroppers, but it should be enough to make many ISPs' routine
  network flow logging less useful in traffic analysis against
  Tor users.

  Padding is negotiated using Tor's link protocol, so both relays
  and clients must upgrade for this to take effect. Clients may
  still send padding despite the relay's version by setting
  ConnectionPadding 1 in torrc, and may disable padding by setting
  ConnectionPadding 0 in torrc. Padding may be minimized for mobile
  users with the torrc option ReducedConnectionPadding. Implements
  Proposal 251 and Section 2 of Proposal 254; closes ticket 16861.
- Relays will publish 24 hour totals of padding and non-padding cell
  counts to their extra-info descriptors, unless PaddingStatistics 0
  is set in torrc. These 24 hour totals are also rounded to
  multiples of 1.

  o Major bugfixes (connection usage):
- We use NETINFO cells to try to determine if both relays involved
  in a connection will agree on the canonical status of that
  connection. We prefer the connections where this is the case for
  extend cells, and try to close connections where relays disagree
  on their canonical status early. Also, we now prefer the oldest
  valid connection for extend cells. These two changes should reduce
  the number of long-term connections that are kept open between
  relays. Fixes bug 17604; bugfix on 0.2.5.5-alpha.
- Relays now log hourly statistics (look for
  "channel_check_for_duplicates" lines) on the total number of
  connections to other relays. If the number of connections per
  relay is unexpectedly large, this log message is at notice level.
  Otherwise it is at info.

  o Major bugfixes (entry guards):
- Don't block bootstrapping when a primary bridge is offline and we
  can't get its descriptor. Fixes bug 22325; fixes one case of bug
  21969; bugfix on 0.3.0.3-alpha.

  o Major bugfixes (linux TPROXY support):
- Fix a typo that had prevented TPROXY-based transparent