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 ...
No, .onion sites are not using https/ssl by default. But the connection inside the Tor network is always encrypted, so it is not really necessary to use https for .onion sites. Exit nodes aren't used at all with hidden services, because the connection stays inside the Tor network until the hidden service is reached.
Increasing the number of hops in a Tor circuit has various impacts :
Performance is decreased since the path is longer and latency is bigger. A bigger path is also less reliable and more failures will occur.
The same goes for Throughput of the circuit. Throughput is better when having three hops.
Anonymity is not enhanced as a matter of fact. Increasing ...
Quoted from TorifyHOWTO (written by me, but never been disputed):
When using a transparent proxy, it is possible to start a Tor session from the client as well as from the transparent proxy, creating a "Tor over Tor" scenario. Doing so produces undefined and potentially unsafe behavior. In theory, however, you can get six hops instead of three, but it is ...
There is a HiddenServiceDir in your torrc. After you have stopped the Tor process, delete the above-mentioned directory and restart Tor. Now the directory contains two new files: hostname and private_key. The name in hostname is now different from the previous version.
Yes, it is possible (through a source-code change), but it is a bad idea. If an attacker is observing (or controls) the first and last hop of your circuit they will very likely be able to de-anonymize you. Changing to four (or more) hop paths doesn't affect the probability of this occurring but it does slow down your Tor connection and increases the load on ...
Tor uses fixed cell sizes. The design document states:
Traffic passes along these connections in fixed-size cells. Each cell is 512 bytes, and consists of a header and a payload.
Apart from that no further mixing or randomisation is used:
No mixing, padding, or traffic shaping (yet): Onion Routing originally called for batching and reordering cells as ...
You can extract the list from Hidden Service lists and search engines which are available at OnionDir - Deep Web Link Directory.
Or you can try Ahmia.fi site which is gathering .onion addresses using various methods by crawling the hidden services, downloading visited page data from the Tor2web nodes, and users can use an HTML form to add new addresses. ...
There are few available Tor2web network gateways:
*.tor2web.fi (managed by Ahmia - Onion Search Engine),
*.tor2web.blutmagie.de (managed by O.Selke with no block),
*.onion.sh (managed by my unknown friend: “hey anon!”).
Source: Tor2web: exposing the darknet on Internet (PDF)
How it works
Whenever you see a URL like http://xxx.onion/, that'...
Maybe think of it as a defense in depth idea. If you only have two hops, and your adversary owns or watched your exit node, they immediately know which other node to compromise to get you.
That single node is a particularly high-value target since you'll be using your guard node for a while, so maybe it's worth investing some resources to be able to watch ...
Some people like http://onion.direct .
However I am a fan of onion.link.
I do know at least in terms of size of GOOG index, the results come out to:
onion.direct | 21k
onion.cab | 232k
onion.link | 1060k
Both onion.link as well as onion.cab do caching. AFAIK the other various t2w gateways do not.
The simplest (relative term) method of breaking onion routing is a correlation attack performed by a global adversary that controls a majority of nodes in the network.
What that means is that somebody watching your entry and exit node can correlate requests coming in from your computer to their entry node at time n and leaving their exit node at time n1 for ...
The creation of the hostname is described in rend-spec, the Tor Rendezvous Specification.
You are 100% correct: There is no central domain name provider on the Tor network. There is no central anything provider on the Tor network.
How it works:
Tor generates two keys for every service on the Tor network. Tor generates a private "secret" key, and a ...
All the nodes after the initial circuit starter are doing rougly the same thing : unwrapping the message by their-and-circuit-starter very own pre-negotiated key ant takig a look at the next layer. After this point four scenario's are in action :
The node is an intermediate, it sees "an envelope with address" in tor network and just passes it by to the ...
Actually, there is an onion address for Tor: http://expyuzz4wqqyqhjn.onion/
The Tor Project runs quite a few onion addresses: https://onion.torproject.org/
I can't confirm if the Tor Browser uses this onion address for updating though.
As far as I can see it from the original onion routing patent, OR uses long term public keys for encrypting messages for onion routers and there is no description of a key exchange.
Tor can be seen as the second generation onion routing (and is intended to have no patent) and besides adding much more features (adding perfect forward secrecy, congestion ...
The path spec doesn't list choosing your own node as one of its constraints on exit nodes:
2.2. Path selection and constraints
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 ...
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 ...
First, let's consider that "the goal is to prevent an eavesdropper on the local end from noticing Tor usage". For argument's sake, let's say that it's easier, at any particular time, to identify all VPN service entry servers than it is to identify all Tor bridges. And let's say that all Internet traffic is logged, and at least metadata (such as IP addresses, ...
Tor and I2P have a number of similarities. Tor however has a big benefit when you are leaving the Tor network. I2P's exit system is basically a really limited set of proxies, which makes attacking you by analyzing the traffic at the exit easier. It's a game of numbers. There are very few exit nodes (they call them outproxies sometimes) compared to Tor.
Yes it can be scanned.
People can scan for services as they do on clearnet, by routing their scanner through tor pointing it at the domain.
A onion domain is not to be considered a secret.
Im not sure about your vpn question, but you can look at this answer here for some hints on how to make the domain private:
Making a movie available via BitTorrent is fine. But using Tor, either for seeding or recommended for downloading, is unwise. It's hard to properly configure torrent clients to use Tor without leaking, so recommending that people download via Tor would put them at risk. And even if torrent clients are properly configured, they would be stealing bandwidth ...
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.
The difference between .onion URLs and normal URLs, is that the normal URL is simply a "human readable pointer" points to a network location... on the other hand, a .onion URL is actually the only address you should be accessing it from. The secure part about Tor is that it masks the server IPs as well.
A government or "knowledgable individual" can tell ...
You build a TLS connection to your guard.
Over that TLS connection you perform a key exchange using the OR protocol. Now you and the first guard compute two keys from the shared secret the key exchange netted you, a forward and a reverse key.
Now you use the first OR to perform the key exchange with another OR, and again both can compute a shared forward ...