Silk Road forums

selectively clogging up parts of the network can force clients toward nodes you control

Which still requires nodes you control. Clients alone can't really deanonymize you.

In all fairness, the Israeli Intelligence Agency (Mossad) quite likely doesn't give a flying fuck what you or anybody else thinks about them

Yet they wrote Stuxnet with mechanisms to prevent widespread infection.

The hits just keep on coming. And by "hits" I mean data showing how weak the Tor network is.

http://cryptome.org/2013/09/tor-analysis-hidden-services.pdf

ABSTRACT

Tor hidden services allow running Internet services while
protecting the location of the servers. Their main purpose
is to enable freedom of speech even in situations in which
powerful adversaries try to suppress it. However, providing
location privacy and client anonymity also makes Tor hid-
den services an attractive platform for every kind of imagin-
able shady service. The ease with which Tor hidden services
can be set up has spurred a huge growth of anonymously
provided Internet services of both types. In this paper we
analyse the landscape of Tor hidden services. We have stud-
ied Tor hidden services after collecting 39824 hidden service
descriptors on 4th of Feb 2013 by exploiting protocol and im-
plementation flaws in Tor: we scanned them for open ports;
in the case of HTTP services, we analysed and classified
their content. We also estimated the popularity of hidden
services by looking at the request rate for hidden service de-
scriptors by clients. We found that while the content of Tor
hidden services is rather varied, the most popular hidden
services are related to botnets.


They turned the Trawling for Hidden Services attack on the users, as we predicted could be done.


5. TRACKING CLIENTS

In [6], the authors used a specific traffic signature for op-
portunistic deanonymisation of hidden services. The tech-
nique they used can be easily modified for opportunistic
deanonymisation of Tor clients.

Assume that an attacker controls a responsible HS direc-
tory5 of a hidden service. Whenever it receives a descriptor
request for that hidden service, it sends it back encapsulated
in a specific traffic signature which will be then forwarded
to the client via its Guard node. With some probability, the
client’s Guard node is in the set of Guards controlled by the
attacker. Whenever an attacker’s Guard receives the traffic
signature, it can immediately reveal the IP address of the
client.

This attack has several important implications. Suppose
that we can categorize users on Silk Road into buyers and
sellers. Buyers visit Silk Road occasionally while sellers visit
it periodically to update their product pages and check on
orders. Thus, a seller tends to have a specific pattern which
allows his identification. Catching even a small number of
Silk Road sellers can seriously spoil Silk Road’s reputation
among other sellers.

As another application, one can collect IP addresses of
clients of a popular hidden service and compute a map rep-
resenting their geographical location. We have computed
such a map for one of the Goldnet hidden services – in Fig-
ure 3.


An informative commentary on the mailing list:

[T]he paper has relevance beyond Tor network flaws:

- It exposes an estimate on how manny hidden services existed at the time of the study.

- It gives a breakdown of what services/some of the services those hidden services offered.

- It categories HTTP(S) services by content type, which is interesting.

- It describes what resources they required to perform the attack, which sound relatively modest.

- It highlights the botnet and botnet command and control activity on Tor.

- It describes server configuration issues that allowed easily correlating the shared hosting of many services

- It describes server configuration issues that allowed easily deanonymizing the true IP Address of some hidden services.

I'm a huge proponent of blockchains shared send and receive wallets.  I think using that alone will cover your ass.

I haven't used that service in a long time, so it may have changed, but the way blockchain.info used to "anonymize" bitcoins was way too vulnerable to traffic analysis. First, they charged a flat fee of 1.5% (which I believe was reduced to 0.5%), and when you sent the coins to your anonymous address, the fee would be subtracted, and the rest would be deposited to your real bitcoin address in exactly two transactions, within about 10 minutes. So if someone identifies your SR address as belonging to SR and they see the deposit came from another address, which they suspect belongs to blockchain.info, because the coins in that address came from two transactions a few minutes apart, then they merely have to look in the block chain for a transaction that occurred about 10 minutes earlier and involved exactly 1.5% (or 0.5%) more BTC. Now they are on the other side of the mixer and they can follow the transaction chain back to the exchange and your identity.

There are much better mixing services that give you more options for how you deposit and withdraw your coins, along with charging variable rate fees, to defend against that kind of traffic analysis.

You shouldn't run a relay from home, because

1. Residential connections are pretty slow to begin with.

2. It destroys one of Tor's best features, concealing the fact that you use Tor. Your IP address will be in publicly accessible lists like http://torstatus.blutmagie.de

3. Many web sites indiscriminately block all Tor relay IP addresses, irrespective of whether they are exit nodes, so you are likely to find your own web browsing to be blocked.

However, I will answer your questions.

hey peoples

I'm trying to setup a tor relay using the browser bundle. I think its working as I get the message saying its " connected to the directory blah blah - excellant"

Problem is.....I'm not 100% sure on the port forwarding that is required.
I'm using port 9001 as the tor relay port, the directory port is  9030 and tor control is localhost:9050. All the tutorials I've read say you need to port forward diff ports..

Do I just need to port forward the tor relay, which in my case is 9001 ?

You should port forward 9001. If you allowed you relay to be a directory server, you should port forward 9030 as well.

Check onion icon -> Message Log -> Advanced tab for messages about whether your relay is accessible by others. It does some self-testing.

Also some docs have the tor relay as 9001 and others as 443, Does it matter what I use ?

443 is better because it's the standard HTTPS port so it's harder for censoring governments to block that port without breaking lots of web sites.

I'm assuming what ever port I use is updated in the directory so others can reach me.. as long as its port forwarded and has connectivity ?

That's correct, although you may not see much traffic for a day or more, while clients are learning about your relay. You also might not see much traffic at all if your bandwidthrate is really low (like below 100 KB).

any other useful tips and tricks would be great

Rent a VPS.

Just published: https://blog.torproject.org/blog/how-to-handle-millions-new-tor-clients


[tl;dr: if you want your Tor to be more stable, upgrade to a Tor Browser Bundle with Tor 0.2.4.x in it, and then wait for enough relays to upgrade to today's 0.2.4.17-rc release.]

Starting around August 20, we started to see a sudden spike in the number of Tor clients. By now it's unmistakable: there are millions of new Tor clients and the numbers continue to rise:

Where do these new users come from? My current best answer is a botnet.

Some people have speculated that the growth in users comes from activists in Syria, Russia, the United States, or some other country that has good reason to have activists and journalists adopting Tor en masse lately. Others have speculated that it's due to massive adoption of the Pirate Browser (a Tor Browser Bundle fork that discards most of Tor's security and privacy features), but we've talked to the Pirate Browser people and the downloads they've seen can't account for this growth. The fact is, with a growth curve like this one, there's basically no way that there's a new human behind each of these new Tor clients. These Tor clients got bundled into some new software which got installed onto millions of computers pretty much overnight. Since no large software or operating system vendors have come forward to tell us they just bundled Tor with all their users, that leaves me with one conclusion: somebody out there infected millions of computers and as part of their plan they installed Tor clients on them.

It doesn't look like the new clients are using the Tor network to send traffic to external destinations (like websites). Early indications are that they're accessing hidden services — fast relays see "Received an ESTABLISH_RENDEZVOUS request" many times a second in their info-level logs, but fast exit relays don't report a significant growth in exit traffic. One plausible explanation (assuming it is indeed a botnet) is that it's running its Command and Control (C&C) point as a hidden service.

My first observation is "holy cow, the network is still working." I guess all that work we've been doing on scalability was a good idea. The second observation is that these new clients actually aren't adding that much traffic to the network. Most of the pain we're seeing is from all the new circuits they're making — Tor clients build circuits preemptively, and millions of Tor clients means millions of circuits. Each circuit requires the relays to do expensive public key operations, and many of our relays are now maxed out on CPU load.

There's a possible dangerous cycle here: when a client tries to build a circuit but it fails, it tries again. So if relays are so overwhelmed that they each drop half the requests they get, then more than half the attempted circuits will fail (since all the relays on the circuit have to succeed), generating even more circuit requests.

So, how do we survive in the face of millions of new clients?

Step one was to see if there was some simple way to distinguish them from other clients, like checking if they're using an old version of Tor, and have entry nodes refuse connections from them. Alas, it looks like they're running 0.2.3.x, which is the current recommended stable.

Step two is to get more users using the NTor circuit-level handshake, which is new in Tor 0.2.4 and offers stronger security with lower processing overhead (and thus less pain to relays). Tor 0.2.4.17-rc comes with an added twist: we prioritize NTor create cells over the old TAP create cells that 0.2.3 clients send, which a) means relays will get the cheap computations out of the way first so they're more likely to succeed, and b) means that Tor 0.2.4 users will jump the queue ahead of the botnet requests. The Tor 0.2.4.17-rc release also comes with some new log messages to help relay operators track how many of each handshake type they're handling.

(There's some tricky calculus to be done here around whether the botnet operator will upgrade his bots in response. Nobody knows for sure. But hopefully not for a while, and in any case the new handshake is a lot cheaper so it would still be a win.)

Step three is to temporarily disable some of the client-side performance features that build extra circuits. In particular, our circuit build timeout feature estimates network performance for each user individually, so we can tune which circuits we use and which we discard. First, in a world where successful circuits are rare, discarding some — even the slow ones — might be unwise. Second, to arrive at a good estimate faster, clients make a series of throwaway measurement circuits. And if the network is ever flaky enough, clients discard that estimate and go back and measure it again. These are all fine approaches in a network where most relays can handle traffic well; but they can contribute to the above vicious cycle in an overloaded network. The next step is to slow down these exploratory circuits in order to reduce the load on the network. (We would temporarily disable the circuit build timeout feature entirely, but it turns out we had a bug where things get worse in that case.)

Step four is longer-term: there remain some NTor handshake performance improvements that will make them faster still. It would be nice to get circuit handshakes on the relay side to be really cheap; but it's an open research question how close we can get to that goal while still providing strong handshake security.

Of course, the above steps aim only to get our head back above water for this particular incident. For the future we'll need to explore further options. For example, we could rate-limit circuit create requests at entry guards. Or we could learn to recognize the circuit building signature of a bot client (maybe it triggers a new hidden service rendezvous every n minutes) and refuse or tarpit connections from them. Maybe entry guards should demand that clients solve captchas before they can build more than a threshold of circuits. Maybe we rate limit TAP handshakes at the relays, so we leave more CPU available for other crypto operations like TLS and AES. Or maybe we should immediately refuse all TAP cells, effectively shutting 0.2.3 clients out of the network.

In parallel, it would be great if botnet researchers would identify the particular characteristics of the botnet and start looking at ways to shut it down (or at least get it off of Tor). Note that getting rid of the C&C point may not really help, since it's the rendezvous attempts from the bots that are hurting so much.

And finally, I still maintain that if you have a multi-million node botnet, it's silly to try to hide it behind the 4000-relay Tor network. These people should be using their botnet as a peer-to-peer anonymity system for itself. So I interpret this incident as continued exploration by botnet developers to try to figure out what resources, services, and topologies integrate well for protecting botnet communications. Another facet of solving this problem long-term is helping them to understand that Tor isn't a great answer for their problem.

Do vendors like to receive the key INSIDE encrypted message or after it (some says inside but there's no point imho)?

I don't know if vendors have a preference. The key is easier to access when it is not inside the encrypted message, obviously since they don't have to decrypt the message. That saves the vendor time, and they are always complaining about things that waste their time. On the other hand, putting the key inside the message gives you more privacy, since anyone who can access your message can import the key and see the key ID. If your key ID can be linked to your forum account and you're trying to separate your forum and market accounts, then it's better to send your public key in an encrypted message.

So.. Since the most sensitive data is being sent on the address form when placing an order, I should paste there my encrypted address and after that my key?

You don't need to send the vendor your key at all unless you expect them to message you with sensitive info. Some vendors send tracking numbers to their customers. In that case, I'd include a message along with my address that says either don't send me the tracking number or use this key to encrypt it to me, but don't send me the tracking number in plaintext, since that can leak my address.

But if you're asking general questions like when the order is going to ship, you don't need and shouldn't expect an encrypted message from the vendor.

Or just use Whonix.