Projects

Simple Bandwidth Scanner

Some of the Tor directory authorities run bandwidth scanners to measure the
bandwidth of relays and include their measurements in their network status
votes. Clients use the consensus of these weights to inform their path
selection process with the hope that every circuit they build will have roughly
equal performance, regardless of the relays chosen. This achieves a form of
load balancing.

Historically, the directory authorities that ran bandwidth scanners (bandwidth
authorities), ran torflow.
Time passed, it slowly become less maintained, and
the collective knowledge of how it worked slipped away.

Simple Bandwidth Scanner (sbws) aims to be a quick to implement, easy to
maintain replacement for torflow.

KIST

KIST is a new scheduler for Tor. It is merged into Tor code as of 0.3.2.9. It
prioritizes low-bandwidth, bursty traffic (web traffic) over high-bandwidth,
continuous traffic. See my relevant publications for more information.

Of those, an unknown fraction are listening on port 80/443 (web sites). The number seems to be no more than 10,000 based on other peoples' attempts at indexing onion services, but let's assume it's all 100,000.

There's 1,208,925,819,614,629,174,706,176 possible v2 onion services

Thus there's an 100,000 / 1,208,925... == 8.27*10^(-18)% chance that any v2 onion service you generate will be up and responding. AKA a 0.00000000000000000827% chance.

This means you are approximately 100,000,000,000 times more likely to win the next Powerball jackpot than the next random v2 onion service you click on/generate/whatever actually being up and responding

Said another way, if you could check 100 billion v2 onion services by the time there's another Powerball drawing (say ... in a week), you have an equal chance of finding one working v2 onion address as you have of winning the Powerball jackpot. This means checking 165,343.9 onion services per second, every second for the next week in order to have a 1 in 292 million chance that one of them is up and responding.

You will never find a working onion service by randomly clicking on links on
my list of all onion services or by randomly
generating links and trying them.

By trying you are wasting Tor network resources. This isn't a problem if you

This post is about v3 onion services with 56 characters in their name. For the
old post for creating private v2 onion services, see
here.

In that old post I talked about some of the great features of Tor onion
services. The features still apply with the new onion services: they are still
end-to-end encrypted, they still assure you that it is impossible for anyone to
modify your traffic, etc.

Regular v3 onions fix the issue that v2 onions had where a malicious HSDir
could snoop and learn about onion services that the owner literally never
advertised. This is great, you no longer have to make your onion service
regular authorization in order to avoid malicious HSDirs. If you never tell
anyone your v3 onion address, no one will ever know it exists.

Regardless of whether you're okay with people knowing your v3 onion address or not,
what if you still wanted to require people to know a secret key in order to
be allowed to connect to your v3 onion service? You can do that now.

If you're going to browse the web, use Tor Browser. Don't try to make Firefox,
Chrome, or something else proxy its traffic over Tor. There is no combination
of settings tweaks that produces as good of a product as Tor Browser. You be
essentially uniquely fingerprintable. You will not get Tor Browser's awesome
state and traffic isolation.

Why you would want HTTPS

End-to-end encryption

You already get this with Tor.

Everything between your local Tor client (using Tor Browser? It runs Tor in the
background) and the Tor client providing the onion service is encrypted. No Tor
relay and no network-level adversary can tell what onion service you are
visiting (which is actually better than what HTTPS-without-Tor to a regular
website would get you).

If you're an onion service operator and you're at the sophistication level of
taking advice from random blogs on the Internet, HTTPS doesn't help you here.
If you're Facebook, Reddit, or YouTube, then you have a sizable datacenter(s)
and are probably no longer running Tor on the same machines as your webservers.
Unencrypted traffic may be flowing over an uncomfortable distance on your
(super secure, right?) network. Maybe you want HTTPS. But you also have the
resources to get a valid certificate for your onion. So do that.

Avoid men in the middle

You already get this with Tor. This is related, but distinct from the previous
point.

When you connect to reddit.com with HTTPS, how do you know no one is MitM'ing
you? The certificate is valid, right? No big scary browser errors. For better
or for worse, we trust the Certificate Authority (CA) system.

When you connect to an onion service, how do you know no one is MitM'ing you?
Easy. It's impossible. The bad guy would have to be in your browser (more
accurately: between the browser part of Tor Browser and the Tor process it runs
in the background) or between the Tor process the onion service operator is
running and the webserver it's pointing at. If you assume your Tor Browser

I'm in the process of setting up a new server and I'm trying to be super ultra
mega secure about it. It's running FreeBSD with some fancy security options
enabled, blah blah blah, oh and I made SSH over Tor the only way to remotely
access it for administration. It's a private onion service,
which is super cool in itself, but since I don't mind leaking the location of
this server, it is also a single-onion service. This does seem to have a
positive impact on the speed and latency to the machine, but after a few weeks
of managing the machine completely over Tor, I determined I wanted more
usability.

My main complaint is the lack of immediate local echoing of what I type. Mosh
does that, but mosh uses UDP, which doesn't work over Tor. There's two ways I
could approach this. The first would actually be called "Mosh over Tor," but I
ultimately went for the second as it would actually allow me to roam (another
great feature of mosh).

I could use socat to tunnel UDP over Tor. Create the tunnel and then mosh to
localhost:some-port.

Or I could authenticate over SSH over Tor and then create the actual UDP
connection over the regular Internet.

So I now present to you the script I use to (not really) use mosh over Tor. It's
a healthy mixture of things specific to me and hardcoded values that need
changing for every use case. But it is a starting point if you would like to
try your hand at (2) above too.