What's new in Tor 0.2.9.8?
Today, we've released the first stable version of the 0.2.9.x series, bringing exciting new features to Tor. The series has seen 1406 commits from 32 different contributors. Please, see the ChangeLog for more details about what has been done.
This post will outline three features (among many other things) that we are quite proud of and want to describe in more detail.
Single Onion Service
Over the past several years, we've collaborated with many large scale service providers such as Facebook and Riseup, organizations that deployed Onion Services to improve their performance.
Onion services are great because they offer both anonymity on the service and the client side. However, there are cases where the onion service does not require anonymity. The main example of this is when the service provider does not need to hide the location of its servers.
As a reminder to the reader, an onion service connection between a client and a service goes through 6 hops, while a regular connection with Tor is 3 hops. Onion services are much slower than regular Tor connections because of this.
Today, we are introducing Single Onion Services! With this new feature, a service can now specify in its configuration file that it does not need anonymity, thus cutting the 3 hops between the service and its Rendezvous Point and speeding up the connection.
For security reasons, if this option is enabled, only single onion service can be configured. They can't coexist with a regular onion service. Because this removes the anonymity aspect of the service, we took extra precautions so that it's very difficult to enable a single onion by mistake. In your torrc file, here is how you do it:
Please read about these options before you enable them in the manual page.
We've talked about this before but now it is a reality. At midnight UTC every day, directory authorities collectively generate a global random value that cannot be predicted in advance. This daily fresh random value is the foundation of our next generation onion service work coming soon to a Tor near you.
In the consensus file, they will look like this; if all goes well, at 00:00 UTC, consensus will have a new one:
Thanks to atagar, the Stem Library version 1.5.0 supports parsing the shared random values from the consensus. See here for more information!
Voluntarily, we haven't exposed those values to the control port yet and will wait for a full stable release cycle in order to make sure it's stable enough for a third party application to use them (https://trac.torproject.org/19925).
Mandatory ntor handshake
This is another important security feature introduced in the new release. Authorities, relays and clients now require ntor keys in all descriptors, for all hops, for all circuits, and for all other roles.
In other words, except for onion services (and this will be addressed with the next generation), only ntor is used--now finally dropping the TAP handshake.
This results in better security for the overall network and users.
Enjoy this new release!
No (unless they do something esoteric like trying to track round-trip timing to guess how many hops are involved).
In the glorious future, when we're using next-generation onion services, the new onion descriptors will have a field where the onion service can say "I'm being a single onion service", and then clients will be able to predict it:
You write, "where an onion service CAN say..." (emphasis added)
This field should be forced to accuracy and uneditable by the service. I remain disenchanted with the idea that a client can swap between three hops and six hops with the client ignorant of when such swapping occurs and how it may impact their anonymity.
You, the Tor client visiting the onion service, still make your own three-hop circuit, which is where your anonymity comes from.
So in the case where you want protection from the onion service, you can't rely on the 3 hops it chooses anyway, because it could be choosing them to hurt you.
You're right that for the case where you want protection from some external attacker, it's not totally clear that just your three hops provides less or the same or more privacy than the full six hops. But I think for most attacks, if your three hops are good then you're good, and if your three hops are not good then you're not good. I would welcome somebody coming up with an attack where the distinction matters in practice. Thanks!