Taken from Tor Path Specification document:
We choose the path for each new circuit before we build it. We choose
the exit node first, followed by the other nodes in the circuit. All
paths we generate obey the following constraints:
We do not choose the same router twice for the same path.
We do not choose any router in the same family as ...
You can use curl to check https://check.torproject.org/:
curl --socks5 localhost:9050 --socks5-hostname localhost:9050 -s https://check.torproject.org/ | cat | grep -m 1 Congratulations | xargs
If everything goes well, the output will be:
Congratulations. This browser is configured to use Tor.
Getting no output (or an error) means somethings not ...
See ticket 7707 for why we added that diagnostic log message in. In short, we were worrying that our round-robin bandwidth allocations would spread bytes too thin over all the connections we write out onto, making the overhead from TLS record headers too high a fraction of the overall bandwidth we use.
This log message is telling you how many extra bytes ...
I want to add some details to alaf's answer:
A Tor circuit consists always of three nodes. Longer paths may hurt your anonymity in the case of Tor.
Exit node is chosen.
Your torrc might have some settings about which exits to (not) choose.
Tor chooses an exit relay which actually allows you to exit the Tor network. Some only allow web traffic (port 80) ...
All the downloads are "signed". This means that someone (in this case Erinn, a Tor Project Developer) vouches that the software is good and hasn't been tampered with.
You can verify the download by also downloading the signature file, and using GPG to check that the signature is valid for the downloaded file, and that they were signed by Erinn.
Tor maintains a descriptor store which keeps all the descriptors it knows about. New descriptors enter the store after being downloaded, old descriptors get expired when they haven't been referenced and are outdated. The client regularly fetches a new consensus document and fetches all the descriptors that it doesn't have and that are referenced in the ...
No, it won't hurt your anonymity and there are no other implications (unless you're severely bandwidth or CPU constrained). Obviously running a relay requires a bit more bandwidth and Tor can be a bit of a CPU hog but any semi-modern processor should be able to handle the extra load fine.
I should note that running a public relay does let people know that ...
The other answers give an overview of what happens, but if you want to learn the consequences of the path selection algorithm you need to have a simulation based on real data. Fortunately there now is one – TorPS which was written for the paper "Users Get Routed: Traffic Correlation on Tor by Realistic Adversaries".
Denial of Service: Tor will be unable to connect, if the system clock is more than 1 hour in the past or more than 3 hour in the future. (ref) Also hidden services can only be accessed if the clock is no more than 30 minutes ahead or behind. (ref)
Tracking: Probably it is possible for guards (or bridges or anybody else who can see the initial connection) to ...
From the §2.2 "Path selection and constraints" of the Path Spec (as of commit 6f2919a2):
Additionally, we may be building circuits with one or more requests in
mind. Each kind of request puts certain constraints on paths:
All service-side introduction circuits and all rendezvous paths
should be Stable.
All connection requests for ...
No. Tor traffic does not necessarily all exit at the same exit node.
For each socket connection that the client sets up, a circuit is used that ends in an appropriate exit node. That is an exit node that allows the IP and port the client is trying to reach.
Ok, I figured this out. For some reason the custom onion address I made with Shallot was no longer working. I made a new hidden service and got rid of the existing one, restarted Tor, and voila! I'm not sure why this happened, but this solved both hidden services that had stopped working.
Short answer is no. It is possible to do so, but would very much lower the anonymous nature of your traffic. It would be best to run A relay node 24/7 to increase the amount of "fast" circuits that you connect to.
You can try out commenting all SocksPorts and ControlPorts, then setting SocksPort 0 and ControlPort 0 in torrc. When Tor is able to connect, then there is a chance, although it requires programming skills. Socks is just an interface for browsers (TBB's Firefox) to communicate with Tor. If you (or pay someone) could teach Tor and Firefox to communicate using ...
Yes, Tor clients encrypt connections to entry nodes (relays). Indeed, they successively encrypt to all relays in the circuits that they specify. The required public keys for all relays are available from Tor's directory servers.
Tor is the 2nd generation of onion routing. In onion routing, the message is encrypted multiple times with a different key for each layer of encryption. In Tor as long as Alice (the client) has established a circuit with 3 nodes, the entry node, the middle node and the exit node, that means that the original message to Bob(the destination) will be encrypted ...
What does Tor Browser test for that fails when using a different / non-local Tor as the client?
With the default settings, Tor Browser:
Starts its own instance of Tor when you first open the browser
Asks the browser what proxy settings have been set in the TorButton Preferences menu
Asks the instance of Tor that the browser started what SOCKS proxy address ...
As far as I see it the answer is in the source code. ;-)
The file main.c has a function run_scheduled_events. The comment to this function says:
Perform regular maintenance tasks. This function gets run once per second by second_elapsed_callback().
Within the source code there is a list of things which this function does. As far as I see it item 2c ...
Good and detailed question, but you're misunderstanding a key point about descriptors. A descriptor doesn't change, once you've downloaded it you don't update it. This is guaranteed by using hashes - if a new descriptor is generated, it will have a new hash value, so the new descriptor is fetched. The check every 10 seconds just means that we'll try to fetch ...
firstly how do you know what hidden services are available, is there a list such as the consensus or is it dependent on knowing about the hidden service you wish to connect to ?
There is no list of hidden services.
If there was this would be considered a vulnerability.
You must know a hidden service's .onion address before you try to connect to it.
I think you've answered your own question.
We don't want the third onion-router in the HS-to-RP circuit to be chosen by the hidden-service client because the client is untrusted and (for all the HS knows) the RP could be controlled by the client.
If the third hop for the HS was the RP, and the RP was controlled by the client, then it's far easier for an ...
The Tor project provides a list of entry nodes, so they can block those by IP address. But then there are bridges that aren't in the list that can act as an entry node. But if the censor is using DPI (Deep Packet Inspection) to examine packets and block those that look as if they are Tor, then a user can try Pluggable Transports aka Meek that obfuscate the ...
There are two different questions lurking here.
When you use Tor to connect to a website, the IP address of the Tor exit node will, of necessity, be visible to the website that is being contacted. In addition, the IP addresses of Tor exit nodes are public, so it is easy for a website to learn that the user is using Tor, which is quite a different matter ...
There are multiple practical reasons where five ORs of bandwidth X MB/s each could be superior to one OR of bandwidth 5X MB/s. There are some restrictions and exceptions to this point in general. This list is not meant to be the comperhensive list of all possible advantages and/or disadvantages, but give you enough clues to get the idea. Let us start and ...
From what I gathered, I have not found anything that point that a client periodically fetch the consensus file. On the other hand, consensus files do expire, and when that happens the client will request the latest version.
If you set TestingTorNetwork in torrc to 1, one of the properties tested will be the frequency of fetching the consensus file. The ...
Every client that doesn't get its consensus from some other source (clients that use bridges get theirs from the bridge they connect to) will have to connect to the Directory Authorities once at first startup, and again if they're offline for a day or longer. Tor metrics should take this into account when calculating user numbers.
Running a relay is a great start if you have the resources, but using Tor for at least some of your daily browsing does help make Tor traffic look more "normal" indeed.
If websites see more of their everyday users coming from Tor then they should see less of a threat. As you come across sites which block Tor traffic, contact the site owners to tell them you ...
(Just to add to the other answers with one that's possibly quite simplistic and obvious... )
So should users like me (who are personally not bothered about
anonymity) follow different recommendations and use Tor for as much
normal activity as possible, to make it easier for others to hide?
Just by using the network you're increasing the size of its ...
TL;DR The answer will depend on what you consider important, and what your Tor use-case is. (Similar to the hand-waving over threat models mentioned in another answer.)
However, in general, the recommendations would be to:
Use fewer guards;
Keep the guards for longer.
These are described in Part 3 of a post on the offical Tor blog, which references 3 ...