Silk Road forums

It's probably due to the massive increase in the number of clients connecting to the Tor network, which has gone from 500K per day to over 2 million per day.

https://metrics.torproject.org/direct-users.png?start=2013-01-01&events=off&end=2013-09-03&country=all

At the same time, the advertised bandwidth in the network has actually decreased.

https://metrics.torproject.org/bandwidth.png?start=2013-01-01&end=2013-09-03

Tor is mostly CPU-bound, meaning that the crypto operations used to build circuits and push encrypted traffic are the limiting factor on the network. High bandwidth relays max out their CPUs long before they max out their bandwidth. Even with 1 Gbit ports, they can only push about 200-300 Mbit of traffic per core.

Some relay operators have posted to the tor-relays mailing list:

https://lists.torproject.org/pipermail/tor-relays/2013-August/002594.html

    I'm currently seeing more than a doubling of connections (from a mean of
    c. 2000 established connections to just over 5000) on my relay at
    0xbaddad. The log is full of the (expected) messages:

    "Your computer is too slow to handle this many circuit creation requests!"

    I guess this is related to the massive jump in connected clients
    in the past few days and I assume that everyone else is seeing
    something similar.

So even though the new clients don't seem to be doing much (bandwidth isn't increasing), maintaining open circuits for 4 times as many clients is straining the relays. The whole network is slowed down with increased lag and a high percentage of failures when connecting to sites. Because circuits to hidden services use twice as many relays as circuits to clearnet sites, we should expect hidden service to be affected more by this.

As for what's causing so many clients to connect, nobody knows yet.

I think that's what DPR is trying to do with the new ratings system. As it stands, it might as well be thumbs up or thumbs down.

May take a while to get people to change their behavior and recalibrate their intuitive sense of what a rating means. Switching to the average out of 5 was a good step in that direction. Whether vendors accept a legitimate ratings system, as opposed to the bullshit one we had, remains to be seen.

You can't install OpenVPN on Tails directly. I mean you can, but Tails uses a weird networking configuration that might now allow it to work, and you'd have to reinstall it after each reboot. The best option is to install OpenVPN on a router that supports it (generally a router with DD-WRT and at least 32 MB of RAM), so your connection goes Tails -> router -> VPN -> tor network.

I just read the paper, which you can get here: http://www.ohmygodel.com/publications/usersrouted-ccs13.pdf

It builds on the work of several other papers that explored the issue of multiple relays in the same autonomous system, or in different autonomous systems that are run by the same organization. For those that don't know, the internet is comprised of thousands of subnetworks that are controlled by different organizations (corporations, universities, governments, etc). For example, your ISP runs an autonomous system. The web site you want to visit is at a hosting provider in a data center that runs an autonomous system (or perhaps several). Large organizations like Amazon with its cloud hosting service (AWS) run autonomous systems in many locations around the world.

OVH is a dedicated server provider that has data centers in multiple locations and many Tor relays run on OVH servers. So a few ISPs like OVH and Hetzner are potentially powerful adversaries. If your entry guard is an OVH server in France and your exit node is an OVH server in Montreal, then OVH can watch both ends of your connection and see who you are and what site you are visiting, thus rendering Tor useless.

The problem is made worse by internet exchange points, which are places where autonomous systems exchange traffic. Someone who controls an IXP can watch the traffic of two or more autonomous systems simultaneously as it traverses those networks. Western intelligence agencies like the NSA and GCHQ are almost certainly tapping many of these IXPs.

This is why we need to diversify the Tor network, and why I suggested running relays in South America and Asia in my relay guide. If you look at a map of Tor relays by geolocation, you'll see that way too many are in North America and Europe. Way too many of the high bandwidth relays are in a handful of autonomous systems, which is especially bad since circuit path building is weighted by relay bandwidth. 20% of Tor circuits will begin and end within an autonomous system that is controlled by the same organization, at any one time!


According to the simulations in the paper, 80% of Tor users can be deanonymized within 6 months through normal Tor use, and without the adversary doing anything special, just watching the networks they already have control over. Interestingly, some of the suggestions they make at the end of the paper to improve security are the same thing we've been saying here for months. Entry guards are the weakest point, so you can increase your security by reducing the number of entry guards (from 3 to 2 or 1) and increasing the entry guard rotation period.

The number of entry guards can be changed in torrc with:

NumEntryGuards NUM

You can manually specify which entry guards you want to use, for example, selecting entry guards that are in autonomous systems where no exit nodes exist. Do that with:

EntryNodes node,node,node

Where "node" can be a relay nickname, identity key fingerprint, or country code (ie, {us},{de}).

You can look up information about relays and ASes on the Tor Compass web site: https://compass.torproject.org

There is no torrc option to increase the entry guard rotation period. You have to modify the source code and compile a custom version of Tor, which I've explained elsewhere on the forum, but it's not a viable option for most people.

A better option may be to use bridges. Since you set them manually, they act like persistent entry guards. There is no rotation period. You keep them for as long as you want, as long as they are up and set in your torrc. Also, since they are theoretically private, the adversary may not know that they are Tor entry point, especially if they are using the obfsproxy protocol to defend against DPI.

Keep in mind that these stats are based on Tor users visiting clearnet sites. It is more difficult to deanonymize hidden service users because the adversary must control specific relays, such as the hidden service's entry guard or service directory, rather than just any exit node. However, it is still possible to attack hidden service users.


There are proposals to make Tor "AS-aware", meaning that it would come bundled with information about ASes and who controls them, and it would avoid building circuits through ASes that are controlled by the same organizations. None of these proposals have been implemented yet (right now Tor only avoids building circuits through relays that in the same /24 subnet, I believe). So it's up to us to defend ourselves against this threat. Probably the safest thing you could do is grab the list of exit nodes, figure out which AS numbers they are in, and who controls them, then find bridges that are in ASes not controlled by those organizations.

any platform that doesnt allow for child pornography, terrorist organizations, drug dealing and general bullshittery is not any platform i want to be a part of.

SR doesn't allow child porn, so bye!

[Info] connection_dir_client_reached_eof(): Received rendezvous descriptor (size 3258, status 200 ("OK"))
[Info] rend_cache_store_v2_desc_as_client(): We already have this service descriptor [scrubbed].
[Info] connection_dir_client_reached_eof(): Successfully fetched v2 rendezvous descriptor.
[Notice] Closing stream for '[scrubbed].onion': hidden service is unavailable (try again later).

Quote

Dissent can guarantee that each user of an online forum gets exactly one bandwidth share, one vote, or one pseudonym, which other users can block in the event of misbehavior.

so a platform called dissent is designed to squash dissent?

It "can" be used that way. Makes it sound like an optional feature, for people who want to prevent spam on their forum, for example. I guess each client is assigned a unique identifier, but I don't know how it works to preserve anonymity.