D-kriptik Blog

Ok, so recently this surfaced and caused a little stir in the Tor world.

Last month, Swedish security specialist Dan Egerstad exposed the passwords and login information for 100 e-mail accounts on embassy and government servers. In a blog entry today, Egerstad disclosed his methodology. He collected the information by running a specialized packet sniffer on five Tor exit nodes operated by his organization, Deranged Security.

This has been discussed here in some form before, and I commented on the trustworthiness of nodes in another form before that.

While there is often logic thrown about that the larger the number of nodes in a mixnet, the stronger the anonymity, such logic often leaves out one key point, the honesty of the nodes. There is a reason remailer networks have traditionally been very small and (at least partially) maintained by some “trusted” nyms. Such honesty problems are not trivial to solve.

So, the real questions here revolve around how well Tor can be made to scale while still achieving its anonymity goals and remaining usable. Increasing popularity not only attracts the attention of more adversaries, but it also means the Tor network itself must grow. With such strong honesty requirements for certain nodes in the network, this growth could pose some particularly interesting problems. (Of course, I am biased in that I always seem to find questions of reputation interesting.)

Once your traffic leaves the Tor network through an exit node, it is no longer, well, in the Tor network. This means the traffic is visible to the exit node (and anyone it passes through from there) without any of the encryption that was utilized as the traffic flowed through the Tor network. If the traffic is plaintext, then the exit node can easily snoop on that traffic. If the traffic is encrypted (say by being piped through an SSL or SSH session), then the exit node could attempt a MITM attack on that traffic, and, especially with regards to the average person using a web browser, many times a user will just ignore any warning dialogs that pop up indicating such an attack.

In this regard, a post was written to Practical Security asking what can be done to mitigate this risk with regards stealing pseudonyms for WWW discussion forums without SSL. I said the following.

1. Use pgp to digitally sign all forum posts. Then your pseudonym is tied to a pgp key pair and not just an account provided by the WWW forum software. If your forum account gets compromised, move on and just keep signing with the same private key – you may even be able to use digital signatures to convince the forum mods to help you here.

2. Rather than utilize rogue nodes when posting to a vulnerable WWW forum, avoid rogue nodes by setting options in torrc (e.g., configuring a set of ExitNodes and turning on StrictExitNodes) to only use particular exit nodes that you deem trustworthy enough not to snoop and such. The lower risk of snooping might be worth the possibly lesser anonymity.

Side note: As another option for performing 2 above, I just noticed the following in here…

– If a user tries to connect to or resolve a hostname of the form <target>.<servername>.exit, the request is rewritten to a request for <target>, and the request is only supported by the exit whose nickname or fingerprint is <servername>.

Now, thinking along the lines of 2 above, I thought it might be nice to excerpt part of a discussion I had a while back.

Trust requirements are not new to mixnets, but the performance objectives of Tor and its large, dynamic network make the issue all the more challenging. AFAIK (and I really don’t know), most P2P metrics can really tell you nothing about the anonymity intentions of a mixnet node – they can cover things like performance or fairness, but you need something like, say, automated open source intelligence gathering tied in with some sort of behavior modeling or, much much simpler, people
intelligence (e.g., the Tor directory server operators), to build a “trust” metric for a mixnet node.

And,

From my take, the core issue here is that the Tor network relies on its nodes (including their operators) to be trustworthy; however, the network currently has no scalable metrics that define and speak to that trust. New nodes are essentially just accepted by the directory servers. From there, performance metrics seem to be used to rank a node’s trustworthiness, if you consider, say, being potentially selected as a guard basically a statement of trust about a node.

My comments on performance being the basis of trust for nodes partially came from a version of this. E.g.,

When a router posts a signed descriptor to a directory authority, the authority first checks whether it is well-formed and correctly self-signed. If it is, the authority next verifies that the nickname question is already assigned to a router with a different public key. Finally, the authority MAY check that the router is not blacklisted because of its key, IP, or another reason.

“Stable” — A router is ‘Stable’ if it is active, and either its Weighted MTBF is at least the median for known active routers or its Weighted MTBF is at least 10 days. Routers are never called Stable if they are running a version of Tor known to drop circuits stupidly. (0.1.1.10-alpha through 0.1.1.16-rc are stupid this way.)

To calculate weighted MTBF, compute the weighted mean of the lengths of all intervals when the router was observed to be up, weighting intervals by $\alpha^n$, where $n$ is the amount of time that has passed since the interval ended, and $\alpha$ is chosen so that measurements over approximately one month old no longer influence the weighted MTBF much.

“Fast” — A router is ‘Fast’ if it is active, and its bandwidth is either in the top 7/8ths for known active routers or at least 100KB/s.

“Guard” — A router is a possible ‘Guard’ if it is ‘Stable’ and its bandwidth is either at least the median for known active routers or at least 250KB/s. If the total bandwidth of active non-BadExit Exit servers is less than one third of the total bandwidth of all active servers, no Exit is listed as a Guard.

So, this discussion went on to convey the following, which is the meat of this post.

You know, I use certain remailers in a chain because I know, or know of, the operators, and I trust them to run a remailer as it should be run. The same goes for my acceptance of remailers in general or Tor.

Which is to say, the reputations certain people have built with me is what I use as a base for my decisions to employ their software and services. Such people’s reputations come from many sources for me. For example… For the people I know, reputations may have been built from all the things that make me say they are people I know, such as debating some aspect of life while sucking down alcohol in a bar together. For the people I know of, reputation may have been built from references from people I know or know of. For both people I know and people I know of, reputation may have been built from longer term exposure to papers, presentations, conversations, discussions, etc. in the appropriate forums. This probably maps to how current directory server operators make their decisions about Tor nodes, and all of these can be mapped to features of a decent social networking service, which is potentially scalable.

Taking a hint from the whole web 2.0 bang, we find lots of people that have links with lots of other people, and the number and quality of such links influences how much value we give to peoples’ opinions. The quality of feedback influences the reputation of the person providing the feedback, which in turn translates to how we value that person’s feedback, which is to say, how much that feedback effects the reputation of the thing being commented on. And so on. This people intelligence that gathers and mines data can lead to a large set of very interesting data, which can then undergo automated analysis. Now, forget web 2.0 though and go old school, the whole PGP web of trust is built on this type of thing.

You could see a Tor social network working in a similar way. People input followed by automated analysis could be the end result. For example, perhaps a system could be created such that node (i.e., node operators) are able to make trust statements about other nodes. The set of statements would be predefined, such as distrust, no trust, marginal trust, or full trust, and have guidelines that node operators should follow to make a determination of trust in a node. The weight of a node’s statements of trust about other nodes could be based on things like that node’s trustworthiness as determined by statements of trust made by other nodes about that node.

With some such metric in place, interesting decisions about a user’s path through the Tor network could be made. The obvious example is requiring specific trust levels for particular places in a user’s path through the Tor network, such as the entry and exit requiring highly trusted nodes but middleman only requiring marginally trusted nodes. As a more interesting example, I imagine a reputation web like that described would lead to clusters of closely linked nodes. Perhaps it would make sense to choose a path through the Tor network that picks nodes from different clusters. Or, if I have made trust statements about the nodes, it might make sense to heavily weight those statements in choosing a path for me – for example, if I fully trust a certain set of nodes, maybe my path through the network should be selected from the set of nodes I fully trust, nodes those nodes fully trust, and so on until there is a “large enough” set of nodes to choose from.

Finally, what I said here was pointed out to me.

In other words, right now, Tor uses the vigilance of people to ward off this type of attack. Such an approach might not scale well, but it works at the moment.

I don’t know if any of this scales well either or if it does more harm than good, but it is an idea nonetheless.

Oh, and for those asking about my Tor node. You know that lovely new motherboard? Well, it appears to have choked.