I wanted to download a file of considerable size, let us say 10GB
and I sent the GET request to a web server to download that file.
I then would get downloaded through the Tor network, through the circuit I had created to request the server to
The question is, if the client stopped reading the TCP connection, would the entire file still be downloaded, or does it depend on the client sending back an ack or something to the circuit asking for the next packet?
hope that makes sense.
Exit relays will continue reading until circuit dies (in old versions) or buffer of a relay becomes too big (in new versions, intended to prevent DoS) .
If you are a 'honest' client, the exit node will only make 1000 cells and then stop reading due to the hard-coded 1000-cell limit on sending window. So yes, it basically depends on something to the circuit asking for the next packet, the RELAY_SENDME cell. A malicious client can do a bit more to kill the guard.
In the efficient version, the adversary controls only a client. She creates a circuit, choosing the victim for the entry position, and then instructs the exit relay to download a large file from some external Internet server. The client stops reading on the TCP connection to the entry relay, causing it to buffer 1000 cells.
The best defense, as we suggested to the Tor developers, is to implement a custom, adaptive out-of-memory circuit killer in application space (i.e. inside Tor). The circuit killer is only activated when memory becomes scarce, and then it chooses the circuit with the oldest front-most cell in its circuit queue. This will prevent the Sniper Attack by killing off all of the attack circuits.
Tor uses handshaking between nodes. If you stop reading from the SOCKS connection of you local tor instance, the exit node which is reading from the server delivering the 10GB file will soon stop reading there, too.
It continues as long as you are connected to a node. Tor makes multiple connections and it has to get pretty bad before it fails.
All though 10gb files over tor is a lot. But one way to make it easier is to use for example a download manager that you pipe through tor that allows you to resume if it fails.
Not all download sites allow I think it is called "restart". If you are using a download manager/optimizer such as the one built into the BitComet torrent client, you can configure how many parallel streams it has open at once (I use 5 generally) and it breaks the file into that many pieces and each runs without paying any attention to the others. When one stream finishes, it goes and steals the latter half of the largest unfinished of its siblings to work on.
That sort of strategy can keep a high capacity connection full in spite of suboptimal outstanding packet limits and small MTUs. However, it can also be easily told to limit the total bandwidth to whatever is you think won't impact the Tor network too much.
Again, the key requirement is that "restart" capability at the site you are going to which enables the tool you are using to indicate where in the file it wants to start getting bytes from.
