Stable release 0.4.8.15

News Tor Release Announcement
1

Where to Download

Changes

Below are the major changes of the released versions and links to more detailed release notes.

Stable

Today, we are releasing the minor version 0.4.8.15 which fixes some minor, but annoying, bugs related to bandwidth authority sandbox and a Conflux control port issue. We also have a minor fix for clients about how they use relay flags for path selection.

As usual, please upgrade to this latest stable version :slight_smile: .

Release Notes

3 Likes
2

Fix client usage of the MiddleOnly flag so that MiddleOnly relays are not used as HS IP or RP by clients or services. … Fixes bug 41023

I poked around The Tor Project / Core / Tor · GitLab commits to see why it was considered a bug that MiddleOnly relays should have anything to do with onion services. I couldn’t find a reason. The comment in src/feature/nodelist/routerlist.c line 603 says /* MiddleOnly node should never be used for HS ndpoints (IP, RP, HSDir). */

Why? Are MiddleOnly relays somehow being used to target/harm onion sites and their visitors?

Is it because guard relays are considered more trustworthy?

To me it sounds like MiddleRelays are now prevented from being Introduction Points, Rendezvous Points, or serving up descriptors. Is that right? Doesn’t that remove an enormous amount of bandwidth support for onion services?

Thank you.

1 Like
3

Bump. Inquiring minds want to know.

Based on the presentations I’ve seen:

  • Onion services publish their descriptors through the normal guard mechanism.
  • (Formerly) all relays could host onion service descriptors, but due to encryption, the descriptors were opaque to the relay. i.e. relays could not know which onion sites they were providing descriptors for.
  • A client wishing to connect to an onion site, obtained the descriptor through the normal guard mechanism, and learned the Introduction Points.
  • Using the normal guard mechanism the client contacts an Introduction Point, and a Rendezvous Point is agreed on.
  • Using the normal guard mechanism, the client and onion service communicate through the Rendezvous Point.

In other words Middle Relays never speak directly to a client that’s not a relay. If they could, then I can easily understand how anonymity would be harmed, just compare the IP address to the list of known tor relays. If an IP address isn’t on the list of known relays, it’s a client, onion service, or bridge. Then the miscreants running the Middle Node send over thugs and kick the door down.

At the Metrics site, it doesn’t break down how many middle relays there are. Relays by Relays Flag is the only place I can see where one could start to try to deduce it. I guess one would subtract Exit and Guard from Running to calculate how many middle nodes there are. But there could be other factors I don’t know, like perhaps a relay is so fast and trusted and the operator set it up to be an exit, but it’s also used as a guard.

Advertised and consumed bandwidth by relay flags shows “Neither Guard Nor Exit” so thus Middle Nodes it seems. And it looks like it’s not a major contributor to bandwidth.

Judging by eye, it appears the bandwidth used by onion services is close to what Middle Nodes contribute. So it seems it’s no great loss to onion services and clients, compared to the total bandwidth available.

But still…my questions remain.

Why keep middle nodes out of onion service usage?

Is there a design flaw somehow people have overlooked until now? Or is it a bug in the code no one found until recently? Something else?

Thank you.

1 Like
4

One should distinguish between a relay that is only in middle position (aka non guard and non exit) and a relay that carries the MiddleOnly flag.

In the past we had bad actors tampering with onion services in an inappropriate manner. Suspects can be “parked” today by MiddleOnly flagging. Where parking is only according to central onion service roles. Those parked relays have still value within the relay chain.

3 Likes
5

Thank you @Felix for attempting to explain this to me.

One should distinguish between a relay that is only in middle position (aka non guard and non exit) and a relay that carries the MiddleOnly flag.

This makes sense. My only confusion in this regard is I thought MiddleOnly was capable of being set in the torrc file. However, a quick search through the man page shows that’s not an option, so I guess only Directory Authorities can set it.

In the past we had bad actors tampering with onion services in an inappropriate manner.

Not surprising and if only it was still “in the past.” :wink:

Ok, so it sounds like miscreants who run malicious relays were able to determine when they were used as an Introduction Point, Rendezvous Point, and/or serving up onion site descriptors. And if so, they behaved “inappropriately,” to put it tactfully.

So the best way to handle them is to station them after a guard, with the exception being an onion service running HiddenServiceSingleHopMode 1 which has no middle hop to a client. Got it, I think I understand now.

Perhaps this page https://gitlab.torproject.org/tpo/core/tor/-/issues/41023 holds details. This issue is referenced in at least one commit I looked at.

Thanks for your time.

2 Likes