I know messing with the way Tor picks relays makes you stand out, but I think if this were to happen for everyone it would reduce the ‘standing out’ problem somewhat.
I think that it is safe to assume that collaboration between intelligence organizations of different countries is not as polished as it can be. There’s always politics, bureaucracy, and the ‘no no, we can do this ourselves’ that could get in the way of international collaboration. Tor might be able to leverage this.
What do you think? Would this be practical and would there be major downsides to this?
One thing I thought about was the cracking of the Enigma machine, where the flaw was that a letter could never become itself after encryption. I’m not sure if some similar exploit could be applicable here, if this were the case.
It’s an interesting idea; it’s come up a few times in the past, sometimes under the heading of “jursisdiction-aware routing” or “topology aware routing”. It’s not impossible, but there are a bunch of factors that make it more complicated than it might otherwise be.
I’m listing these here, not to say “This could never be done” but rather to explain why it’s hard to do right.
In no particular order:
The country where an onion router is located physically isn’t necessarily the country that can exercise control over it. For some attack models, it matters which countries could coerce the operator, or the company hosting the relay—not just the ones that could seize the router.
For most network attacks, it’s important to look not only at the network where the exit is located, but at everything between the exit and your actual destination. For example, if your exit is in Germany but you’re connecting to a website in the US, your traffic patterns are observable on all the networks in between. Therefore, a real solution to this kind of thing is going to (possibly) require a big network map.
But when we start making a stream, we don’t know the IP of the stream destination, so we don’t know which country it’s in.
The country where the user starts also matters, since their traffic to their guard transits all the networks in between. For example, if a user is in Germany but their guard is in the US, all their traffic to the guard transits multiple international networks. So we’d want to take the user’s location into account too.
But people move around; should we start having a separate set of guards depending what network the user is on? That might be a good idea, but it does create a problem if the local DHCP is hostile, and tricks the user into thinking they are moving around in order to force multiple guard selections.
GeoIP databases are okay, but not perfect, and they’re mostly not designed to resist active attacks AFAICT. We’d need to think about the threat model implications of having an adversary who can mess with a GeoIP database, and make sure that we haven’t actually made the situation worse by using giving such adversaries an easier attack than they had before.
You’re right to think about an analogy to the Enigma attack. Supposing that we never use an exit in the same country as a guard. And suppose that a user has some linkable connections: for example, they log into a forum with the same username over a bunch of different exits. The forum could see which countries these exits were coming from, and thereby narrow down the place where the user’s guard was. (I’m not sure how bad this attack is, but it’s something to consider!)
I think that the research field may be finding its way towards good solutions here, though. Here are a few different papers about AS-aware routing, published over the last decade or so. I don’t think they’ve come up with a definite practical solution yet, but I do think they’re getting closer.
IMO, the the best simple path forward at this point would be to go over the research literature and see if there’s a nice, simple, not-too-complex design with some really solid analysis on it. Then we’d want to specify it, look or attacks, and iterate from there.
Anyway, I hope that was interesting! I’m not as familiar with all the recent research literature here as I’d like to be, so I hope folks will let me know if there’s anything crucial I’ve missed.
Does anyone know if the network development team have been forwarded a link to this thread or would it not be worth asking something that’s been questioned since 2011?
It would be good if the circuit is created in such a way that both the entry and exit were guaranteed to be in two differing countries but neither of them being members of 14 eyes.
I would also like to ask for clarification about where you say
How do you mean observable on all networks? To my understanding the only two networks involved would be that of the website and of the exit node. The node only sees the site and the exit doesn’t know the IP or country of the middle relay or entry. Have I gotten this wrong?
I think trying to keep the entry as far away from the exit is probably a good thing, with cell padding it can maybe help against analysis attacks too?
Edit: Additional question, as if there weren’t enough already
Some people have said that HTTP/HTTPS websites see the exit node IP address whereas .onion sites apparently don’t see the exit node IP but rather the middle node IP since traffic to hidden services doesn’t exit out of Tor meaning exit nodes are unnecessary, is that true and if so doesn’t it technically mean all hidden service users are actually only two hops away?
I’m talking about your traffic as it goes to the website from the exit. Even if it’s encrypted, it still has to travel over the internet from point A to point B. For instance, when I send (regular, not Tor) from my computer in Boston to a randomly chosen website in Germany, it travels through New York, then through the UK, and then to Germany.
Traffic to an onion service uses a 6-hop path, where the client chooses three hops and the onion service chooses three. The two halves of the path meet in the middle, but neither one is exactly an “exit”.
For information how onion services work, have a look at this handy overview.
Does anyone know if the network development team have been forwarded a link to this thread or would it not be worth asking something that’s been questioned since 2011?
Ah yes now I understand what you meant. Would the passage of encrypted data be an issue because they can still tell it’s Tor traffic? I would assume it’s pathway would only leave traces of unlinkable metadata which becomes scrambled within however many networks it must pass through to reach the end point. To agencies I would imagine this information is absolutely useless but obviously people in a better position of understanding have presumably found otherwise?
That’s reassuring to hear, I thought it all operated under the standard of three (or possibly even two in the question I asked) so to know it’s actually 6 different points is very good.
Thank you for the links, I did scroll past the 'how onions work’s article a while back but assumed it would be heavily technical for advanced users or onion operators.
This one solves the practical issues of those listed papers
I’d argue that the solution is practical, but I am not sure that it would be a good idea anyway! There is no free lunch: if we want the same performance experience as the vanilla path selection (on average) with a security location goal criteria, we would be forced to make worse other kind of problems, e.g., Guard Placement Attacks. The good news however, is that we can bound this issue
