Tor Project has just released version 0.3.2.1-Alpha of tor that supports the long-awaited, next-generation onion services that aim to repair many its known flaws. Here’s what I understand are the big changes and features compared to the old version.
Onion services right now are based on RSA 1024 bit keys which, for long-term keys, aren’t an ideal size. While RSA 1024 hasn’t been publicly cracked, predicts say it should be possible this year. In any case, RSA 1024 has been phased out for years and shouldn’t be used.
Related, this factors into to the debate about not needing HTTPS on an onion service because onion services have end-to-end encryption through the Tor Network. This encryption was RSA 1024 and so while yes it was encrypted, some would say that it’s not sufficiently encrypted. Most Internet service have replaced RSA 1024 keys withs something much stronger like 4096bit keys or it’s ECC equivilent.
In the next generation, RSA is dropped completely from onion service and replaced with eliptical curve crypto. Other areas of the tor protocol have dropped RSA as well so this is in-line with their normal practices and industry standards. Compared to the other changes, this was a relatively simple fix.
All onion service communications are based on the RSA 1024 bit key and a SHA1 hash for the address. That sentence makes a lot of crypto or security people cringe. This year, SHA1 has officially been cracked by a team at Google and it should be phased out of use in critical systems such as tor.
SHA3 and the Keccak crypto family comes in to replace SHA1. This is a stronger algorithm which makes it much more difficult for an attacker to spoof an onion address, but at the same time, it means that those 16 character, short onion addresses (like antitreevysdy5cv.onion/) are going to be longer. Much longer. 52 characters to be exact (like 4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad.onion).
This is going to open up some additional required support services like an onion name service to help build memorable domains that point to onion service addresses.
A long time ago, in a galaxy with less statistical information and a different threat model, tor chose their first hop (then called “Entry Nodes”) randomly for every circuit. It turns out that if you have a global passive adversary, then there is an extremely high likelihood that one of the circuits you choose will use a compromised “Entry”.
To address this, they replaced “Entry Nodes” with long-term “Guard Nodes” in 2014. These are three specific entry points into the Tor Network that your client uses over and over. If you create 100 circuits, each one of those circuits will use the same guard. This reduced the likelihood that one of your circuits would be compromised. They did the math.
For example, an attacker in position to intercept your connection sees that you are making encrypted connections to the three guard IPs, and blocks those IPs. (This could be your ISP or your favorite fascist enterprise firewall.) Your client reacts by choosing a new guard – and that gets blocked. This process repeats until you finally choose a guard node that is compromised by the attacker and in that case, your circuits will be compromised on a permanent basis. This isn’t overly difficult to pull off when you consider that all entry nodes are public information and by simple injecting a single RST packet you’ll re-negotiate your connection. Those doesn’t mean a complete compromise of your communications, but it does mean that they’ve built the first piece of the exploit to do so.
To prevent these types of attacks and to improve on the guard selection process, they’ve introduced what looks like a kind of a state machine for the guard selection process. Instead of you choosing Fascist Firewall, Bridge, or Normal before connecting to the Tor Network, this will be done for you by process of elimination. They call this new selection process Vanguards and it aims to make even active attacks on the client side, have less of an impact.
If you wanted, and had the resources to do so, you could spin up hundreds or thousands of relays and become an HSDir. The onion service descriptor value for an onion service is uploaded to you as the HSDir and with that you could figure out a service’s onion address. That’s because the public key (the one used to determine an onion service’s address) is included in this descriptor. It looks like this:
SHA1(onion address || SHA1(time-period || replica))
This was actively being used as an attack vector especially by people that wanted to see what onion services were online or monitor their popularity. You may remember a presentation at CCC from a few years ago that did this and concluded that most if not all of the onion services were used for pornography.
This attack seemed like a pretty big deal to me. This in effect meant that you could figure out how many people that happened to use your relay, were accessing a single onion service, as well as discover services that should have been completely unknown. When trying to push the idea that the Tor Network is good for managing your IoT devices, it was based on the idea that no one would be able to know the address of your device.
The fix is straight-forward in concept: There’s no specific reason to include the public key of the onion address in the service descriptor. It’s simply used as a way of authenticating that an onion service is truly yours. So why not perform the same function but with a subkey off of your master key used for the onion services. There is no way to derive the master key (onion address) from the subkey but you’re still able to authenticate the key as being owned by the service.
This means that the onion address can never be discovered by my friend’s threat intelligence company (hi!) who is running a bunch of HSDir’s. They’ll have to figure out another way.
What I don’t know yet is if you still did this attack on the new onion services, would you be able to see an onion address’s subkey and continue to track it’s popularity? I might not be able to see that a key corresponds to an onion address, but could I see how popular some onion services are?
If you followed the above malicious HSDir scenario, you’ll be pleased
to know that it’s even easier to exploit. You can also work
hard to be one of the 6 HSDir’s for a designated onion service. This works by taking the
replica I mentioned
above which are predictable, and brute force a hash that is appears before
all others. The attack is outlined here
The fix is to use the new shared randomness hotness. This came out earlier this year but I didn’t really understand why. Finally it seems relevant to me. The short of it is the shared random value is stored in the consensus document and everyone agrees to it but it cannot be predictable. Because it’s not predictable, it can be used with the descriptor file so that others can’t predict its values and forcefully become one of the HSDir’s for the service.
Previous versions of tor required that onion services make a double circuit to the rendezvous point. That’s the central hop where the onion service and the client meet. This was basically a circuit for the client and a circuit for the service. The goal was you could provide anonymity properties to both sides.
But then Facebook entered the onion service game and they became one of the first big sites that cared more about performance than anonymity. They didn’t care about the anonymity properties provided by making a circuit from the onion service to the rendezvous point.
So they let you get rid of it.
Now you can specify your service as a Single Onion Service which will only make a single client circuit from the client side, and let the server side connect directly to the rendezvous point. This improves latency because you’re removing 2 unnecessary hops from the connection and it cuts down on the amount of tor network resources required.