Silk Road forums
Discussion => Off topic => Topic started by: Locutus of Borg on February 22, 2013, 04:59 pm
-
I'll try keep this concise. I've been given an assignment for a networking course in which I must research a particular topic and write a report on it. One of these topics happened to be Overlay Networks which Tor falls under. Now, while I believe I'll have no problems researching and writing about the theory and functionality of Tor I'm struggling to formulate any ideas for a practical exercise relevant to the research.
So what I'm asking, is for suggestions for a possible practical project on the tor network. Any suggestions would be very much appreciated although it'd be nice to hear from some forum members with plenty of knowledge on Tor. Keep in mind also that I haven't got sophisticated equipment and it does not have to be overly complicated.
If anybody does opt to help me, thanks a million.
-
Determine if cross circuit timing attacks work, despite sending only one packet.
The problem:
clients keep muliple circuits open, even while they are not in use. Imagine 1 is an attacker controller node and 0 is a good node. A clients set of open circuits may look as follows:
1 - 0 - 0 -> null
0 - 1 - 0 -> null
0 - 0 - 1 -> destination
when Tor is exited, a shut down packet is sent through each open circuit. I propose that a timing attack on the shut down packet can be used to link traffic across multiple circuits, allowing the attacker who owns the '1' nodes to link the client to destination, despite not being able to observe the traffic on entry and exit.
This is now recognized as a theoretical attack, however there is some amount of debate as to if it will work on the deployed Tor network. On a Tor network with a single user, it is certain to work. With as many users as there are on the current Tor network, some people think noise may prevent this attack from working with the single shut down packet. I strongly believe that the attack will work on the deployed Tor network, however there has not been any research done on this attack to date.
-
Although researching it further is on the list of things to do for the Tor research community, nobody has any papers on it yet and nobody has as of right now researched this as far as I am aware.
-
Having been around for the best part of a year you were one of the people I had hoped would reply to this thread, you seem to know your way around Tor quite well. This is a good suggestion but I'm not sure if I have the level of expertise to carry it out, especially considering that there has been, as you mentioned, little to no research done on it. However, I'll certainly make an attempt at understanding and doing it so cheers for your input.
-
You say a networking course; is this a graduate course you're taking because it's related to your PhD dissertation, because it's part of the requirements for your MS, undergraduate course that you're forced to take because you're a first year, or...?
And is this course in a computer science department, or what...? It's hard to suggest a project without any clue what aspect you're expected to focus on.
-
That's a good point SS, I should have been a bit more informative in my original post. Anyway, to answer your questions it is a compulsory module in an undergraduate Computer Science Course. the practical is just one section of my research project so it need not be too intricate.
Cheers for your reply.
-
Here's a practical project for you: how the fuck do you automatically configure a program to work transparently through Tor in Windows using the Tor Browser Bundle? As far as I can tell from an hour of poking about, it's outright impossible.
They switched the listening port Tor uses from 9050 to 9150, the bundle allows the Tor config files to exist anywhere the user decompresses the bundle and executes it from, and there are no environment variables set indicating what port Tor expects incoming connections on.
... yeah, that's pretty lame, I agree. Just an issue I bumped into earlier today, that's all. I thought I was going to be able to think of something, but after sitting here for several minutes, very little is coming to mind... I'm beginning to see why you asked the question, hah...
Well if you want something really simple but dangerous enough to not be given a low grade because of lack of complexity, write a tiny little script that an exit node could use to replace the Tor browser bundle download mid-stream with a tiny executable file that says "pwned" when run or something silly like that. I'm not sure how effective the readily available SSLStrip software is though, so it may be more problematic than I'm making it out to be.
Yep, it turns out I have no ideas at all, basically. For what it's worth, good luck though.
-
Determine if cross circuit timing attacks work, despite sending only one packet.
The problem:
clients keep muliple circuits open, even while they are not in use. Imagine 1 is an attacker controller node and 0 is a good node. A clients set of open circuits may look as follows:
1 - 0 - 0 -> null
0 - 1 - 0 -> null
0 - 0 - 1 -> destination
when Tor is exited, a shut down packet is sent through each open circuit. I propose that a timing attack on the shut down packet can be used to link traffic across multiple circuits, allowing the attacker who owns the '1' nodes to link the client to destination, despite not being able to observe the traffic on entry and exit.
This is now recognized as a theoretical attack, however there is some amount of debate as to if it will work on the deployed Tor network. On a Tor network with a single user, it is certain to work. With as many users as there are on the current Tor network, some people think noise may prevent this attack from working with the single shut down packet. I strongly believe that the attack will work on the deployed Tor network, however there has not been any research done on this attack to date.
Apologies for hijacking the thread, OP: I'm not following you, kmfkewm. Aren't there generally 3-6 hops in a circuit to a destination, 3 circuits being standard to have open at any given time? On an actually real network that would make the chances of being in a position to identify someone this way -- well, effectively nil. Probably as close to 0 as you can get if you're actually after a specific target and not just any target that you happen to find yourself in the magical position to out. ... Right? You'd have to have as many open circuits as hops in the chain, all of which were positioned at the exact point they need to be, plus the target would have to have that many circuits open as well and you'd have to both basically have the same exact paths. Oh, you know what I mean -- you'd both have to be making up the majority of the chain together is more what I mean.
The chances of that happening, are just... I don't understand how that could ever happen in the wild? What am I missing here?
-
I'm quite confident in the knowledge that I would not be able to figure out the answer to that question you so elegantly asked.
Anyway, I do appear to have dug myself into a deep hole in choosing this topic since the practical aspect is worth quite a large deal. The other topics just seemed so mundane though, writing several thousand words and doing a practical on topics like the transition to IPv6 just didn't appeal to me in the slightest. Oh well, I'll have to keep thinking and hope something pops into my head, as unlikely as that is ...
Thanks again for trying to help.
-
Well if it isn't too trivial for your academic standing (as in what year you're in), you can just make a proof-of-concept Ruby or Python script that... does... something with Tor. I mean like, anything with Tor.
Here's the basic stuff required (I didn't try to run this, but it should be fine):
# standard, comes with Ruby distribution
require 'uri'
require 'logger'
# Requires the "socksify" gem, type "gem install socksify" to get it
require 'socksify'
# requires the "mechanize" gem
require 'mechanize'
# enable debug output
Socksify::debug = true
# enable super verbose debug output
Mechanize.log = Logger.new(STDOUT)
# set all TCP connections to transparently go through Tor
TCPSocket.socks_server = '127.0.0.1'
TCPSocket.socks_port = 9050
# create a mechanize object that will act as our agent & fetch web pages for us
agent = Mechanize.new
# get the page at www.google.com
page = agent.get(URI("www.google.com"))
# print out the HTML source
puts page.root
=begin
Cool stuff goes here, y0!
=end
Tada. Proof of concept "use the Tor proxy," Ruby script.
-
Or if you need to write a report or something, do one about the Tor2Web service (tor2web.org I think). You could fluff a paper out of it, probably. Anyway, good luck! :)
-
I'd doubt it's too trivial for the level we're at at the moment, I haven't even got any experience with Ruby or Python (only Java and some C so far) but I'll certainly try work with what you've given me and I can always run it by my lecturer to see whether it would suffice. Thanks once again SS.