Up to at least October 2013 the hidden services work like this:
A hidden service calculates its key pair (private and public key, asymmetric encryption).
Then the hidden service picks some relays as its introduction points.
It tells its public key to those introduction points over Tor circuits.
After that the hidden-service creates a hidden service ...
Tor clients do not, in general, directly do DNS requests. When you open a connection through the tor network you usually ask your client (on its socks ports) to connect you to a hostname and port, say www.example.com:80.
Your tor client, once it has created a circuit, will send that hostname and port to the exit node in its RELAY_BEGIN cell.
The exit node ...
It doesn't resolve them in the common sense - there is no DNS involved at all.
It looks up their introduction point on the hidden service directories - see Is it possible to look up the public key for a .onion-address?.
Then a rendezvous point is set up where the hidden service and the client meet -
answers to How do onion addresses exactly work? have more ...
In theory, it should be just a matter of fetching /tor/rendezvous2/<hidden service identity> via HTTP from the hidden service directory responsible for that hidden service, as per the rend spec, in particular section 1.6.
In practice, you need to find the right server to download it from and then form the request correctly. That's a bit icky to do ...
TL;DR — Yes, traffic is end-to-end encrypted between the client and the server node.
To understand why, it's important first to clear up a misconception in the original question:
when Alice don't know destination node's key how is that possible
encrypt traffic on this point?
Alice does know the destination's public key (identity) and visa versa. Keys ...
All Tor circuits contain 3 nodes by default (passing over hidden services which work a little differently and essentially use two circuits chained to a gateway node). Any more than this does not add any extra anonymity.
While it is possible to change the number of nodes by modifying the source code, this is not recommended. Any less than three nodes and ...
You have to remember, that Tor is a PROXY. Proxies act on behalf of another, and therefore, theoretically you would only need to "resolve" the address of the first node of the circuit. But you don't have to do that, because Tor already has that information in its configuration files.
What happens is that the exit node "handles" everything, including DNS, ...
Requesting a NEWNYM over the control port will tell Tor to consider the currently used circuits "dirty" (this normally happens after 10 minutes, with a few exceptions), at this point it will no longer attach new streams (connections) to the "dirty" circuit, and instead will attach them to a "clean" circuit (it doesn't normally build a fresh one at the time, ...
The RDP protocol in its default configuration is vulnerable to a man-in-the-middle attack. Administrators can enable transport layer encryption to mitigate this risk.
RDS over TLS is somewhat equivalent to https. So if you trust Tor with https traffic you can probably also trust it with RDS over TLS.
If you're dealing with proprietary ...
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 ...
While nickm's answer of "Use SOCKS, that's what it's there for" is correct, I think you might be asking the wrong question. If you want to get information about other aspects of Tor, but don't want to perform queries, implement SOCKS, etc. yourself, you can always use one of the existing libraries. In Python, for instance, you can use Stem.
If you're ...
Tech specs are hosted in git repositories, along with other Tor projects:
The specs repo:
The Tor Protocol Specification:
This may be useful as an example: http://chattorci7bcgygp.onion/
Webservers generally accept many simultaneous connections, and process many requests simultaneously. As Peter Palfrader aka weasel notes in his answer, the Tor hidden service protocol can also handle multiple simultaneous connections.
Users see the webserver's public hostname, and connect via Tor circuits. The webserver sees users coming from virtual ports ...
The Tor spec says:
5.3. Creating circuits
When creating a circuit through the network, the circuit creator
(OP) performs the following steps:
Choose an onion router as an exit node (R_N), such that the onion
router's exit policy includes at least one pending stream that
needs a circuit (if there are any).
Choose a chain ...
Could somebody explain step-by-step?
A good starting point on the entire process is here.
Why nobody can extract all onion domains from Tor network?
The Tor network is deliberately decentralized so that no one has a complete list of the .onion addresses available. A distributed hash table (DHT) is used in the process of connecting a server and client, ...
This isn't a good idea.
TCPCrypt is, and I can't stress this enough, absolute trash.
It provides no protection against an active MITM attacker, it's not authenticated.
The remote party too must support TCPCrypt, otherwise it won't work.
Any remote party could just use TLS or an onion service and gain greater protection than that offered by TCPCrypt.
There is always a way to be monitored by your ISP, because your information (packets) goes through its physical infrastructure (usually fiber cable)
at least there is a way to know if you are connected to a tor relay (not the information going inside the packets that is encrypted),
some ISPs do that in order to prevent their clients to connect ...
Just looking through code on git
int NewCircuitPeriod; /**< How long do we use
a circuit before building... **/
Which makes me think that if "10s of hours" in seconds is easily overflowing an int. try around 30000 maybe?
TOR cell size is 512 bytes but most TOR packets have size of 586
bytes. My question is that why there is such difference in size (74 bytes difference)?
The 586-byte packet being referenced in the papers is Tor's 512-byte cell wrapped in the headers of three different protocols: TLS, TCP, IP.
In my set up, using Wireshark, I'm seeing lots of outgoing ...
I did some testing on my own and my conclusion is that the connection is in fact established outside the tor browser sandbox. The tor browser is merely functioning as some kind of "window" for the ordinary OS-specific SMB communication. That means that the tor users actual private IP is used in this case. Good to know.
As the digest of the descriptor is done the same way the fingerprint is calculated both have a binary length of 20 bytes (40 bytes in hex notation).
So the same limit applies for the descriptor digest.