Re: Need to run UDP & ICMP through Tor
On Sat, 22 Sep 2007 13:27:03 -0400, Roger Dingledine wrote: > On Sat, Sep 22, 2007 at 01:21:59PM -0400, misc wrote: >> Is there a way to torrify UDP (I'm not talking about DNS) and ICMP? >> >> For example how can I ping somebody through Tor? > > No. At least, not in 2007. > > http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP > > --Roger OK, I'll keep my fingers crossed...
Tor 0.2.0.7-alpha is out
This seventh development snapshot makes bridges work again, makes bridge authorities work for the first time, fixes two huge performance flaws in hidden services, and fixes a variety of minor issues. The Windows bundle also includes the new development Torbutton version 1.1.7, which clears cookies and disables a lot of other dangerous web behavior: http://torbutton.torproject.org/dev/ Windows users are encouraged to back up their Firefox settings before upgrading. https://tor.eff.org/download.html Changes in version 0.2.0.7-alpha - 2007-09-21 o New directory authorities: - Set up moria1 and tor26 as the first v3 directory authorities. See doc/spec/dir-spec.txt for details on the new directory design. o Major bugfixes (crashes): - Fix possible segfaults in functions called from rend_process_relay_cell(). Bugfix on 0.1.2.x. o Major bugfixes (bridges): - Fix a bug that made servers send a "404 Not found" in response to attempts to fetch their server descriptor. This caused Tor servers to take many minutes to establish reachability for their DirPort, and it totally crippled bridges. Bugfix on 0.2.0.5-alpha. - Make "UpdateBridgesFromAuthority" torrc option work: when bridge users configure that and specify a bridge with an identity fingerprint, now they will lookup the bridge descriptor at the default bridge authority via a one-hop tunnel, but once circuits are established they will switch to a three-hop tunnel for later connections to the bridge authority. Bugfix in 0.2.0.3-alpha. o Major bugfixes (hidden services): - Hidden services were choosing introduction points uniquely by hexdigest, but when constructing the hidden service descriptor they merely wrote the (potentially ambiguous) nickname. - Clients now use the v2 intro format for hidden service connections: they specify their chosen rendezvous point by identity digest rather than by (potentially ambiguous) nickname. Both are bugfixes on 0.1.2.x, and they could speed up hidden service connections dramatically. Thanks to Karsten Loesing. o Minor features (security): - As a client, do not believe any server that tells us that an address maps to an internal address space. - Make it possible to enable HashedControlPassword and CookieAuthentication at the same time. o Minor features (guard nodes): - Tag every guard node in our state file with the version that we believe added it, or with our own version if we add it. This way, if a user temporarily runs an old version of Tor and then switches back to a new one, she doesn't automatically lose her guards. o Minor features (speed): - When implementing AES counter mode, update only the portions of the counter buffer that need to change, and don't keep separate network-order and host-order counters when they are the same (i.e., on big-endian hosts.) o Minor features (controller): - Accept LF instead of CRLF on controller, since some software has a hard time generating real Internet newlines. - Add GETINFO values for the server status events "REACHABILITY_SUCCEEDED" and "GOOD_SERVER_DESCRIPTOR". Patch from Robert Hogan. o Removed features: - Routers no longer include bandwidth-history lines in their descriptors; this information is already available in extra-info documents, and including it in router descriptors took up 60% (!) of compressed router descriptor downloads. Completes implementation of proposal 104. - Remove the contrib scripts ExerciseServer.py, PathDemo.py, and TorControl.py, as they use the old v0 controller protocol, and are obsoleted by TorFlow anyway. - Drop support for v1 rendezvous descriptors, since we never used them anyway, and the code has probably rotted by now. Based on patch from Karsten Loesing. - On OSX, stop warning the user that kqueue support in libevent is "experimental", since it seems to have worked fine for ages. o Minor bugfixes: - When generating information telling us how to extend to a given router, do not try to include the nickname if it is absent. Fixes bug 467. Bugfix on 0.2.0.3-alpha. - Fix a user-triggerable (but not remotely-triggerable) segfault in expand_filename(). Bugfix on 0.1.2.x. - Fix a memory leak when freeing incomplete requests from DNSPort. Found by Niels Provos with valgrind. Bugfix on 0.2.0.1-alpha. - Don't try to access (or alter) the state file when running --list-fingerprint or --verify-config or --hash-password. (Resolves bug 499.) Bugfix on 0.1.2.x. - Servers used to decline to publish their DirPort if their BandwidthRate, RelayBandwidthRate, or MaxAdvertisedBandwidth were below a threshold. Now they only look at BandwidthRate and RelayBandwidthRate. Bugfix on
Re: Load Balancing
On Sat, Sep 22, 2007 at 03:51:07PM -0400, Anthony DiPierro wrote: > > If the user started churning through circuits at five times the current > > rate, we may end up forced to move the "10 minute" value back even farther > > to compensate, resulting in even more user connections becoming linkable. > > > Why does new circuit creation use up so much CPU? Are you spawning a > new thread for each circuit, or something? If so, maybe there's a way > to be more efficient instead? It's because of the crypto. Each server on the path needs to do two public key operations for each new circuit -- one to ensure perfect forward secrecy, and the other for authentication. See e.g. https://tor.eff.org/svn/trunk/doc/design-paper/tor-design.html#subsec:circuits or Section 5.1 of https://tor.eff.org/svn/trunk/doc/spec/tor-spec.txt If you still want to read after those, also see http://freehaven.net/anonbib/#overlier-pet2007 and http://freehaven.net/anonbib/full/date.html#kate-pet2007 --Roger
Re: Load Balancing
On 9/22/07, Roger Dingledine <[EMAIL PROTECTED]> wrote: > Once upon a time, the value of "10 minutes" was actually more like 1 > minute. You see, the shorter it is, the fewer actions from the user are > linkable with each other based on being in the same circuit. But Tor > server operaters complained they were using 100% cpu because they were > constantly handling new circuit creation requests. So we moved it back to > 10 minutes -- bad for user security, but necessary to keep things working. > > If the user started churning through circuits at five times the current > rate, we may end up forced to move the "10 minute" value back even farther > to compensate, resulting in even more user connections becoming linkable. > Why does new circuit creation use up so much CPU? Are you spawning a new thread for each circuit, or something? If so, maybe there's a way to be more efficient instead? I know, I know, I shouldn't complain if I'm not going to offer code. So don't consider this a complaint, just a question.
Re: Load Balancing
On Fri, Sep 21, 2007 at 03:06:39PM -0700, Michael_google gmail_Gersten wrote: > If you have a web page with 30 sub-fetches (images, style sheets, > script files, etc), then they will all fetch over a single circuit. > > It does NOT make sense from a performance point of view. Since > everything will be encrypted, regardless of which circuit it takes, > there is no performance impact. Actually, here's one reason why using circuits one by one rather than all at once is good for performance and ultimately good for security. Imagine you make five circuits preemptively. Scenario one is that you use them one by one, discarding them and switching to a new one when the current one becomes dirty (defined as "first used more than 10 minutes ago"). Scenario two is that you use all five of them for fetching your big web site, discarding them when they become dirty. Now compare the two scenarios in terms of total number of circuits the user needs to make over the course of a day. Once upon a time, the value of "10 minutes" was actually more like 1 minute. You see, the shorter it is, the fewer actions from the user are linkable with each other based on being in the same circuit. But Tor server operaters complained they were using 100% cpu because they were constantly handling new circuit creation requests. So we moved it back to 10 minutes -- bad for user security, but necessary to keep things working. If the user started churning through circuits at five times the current rate, we may end up forced to move the "10 minute" value back even farther to compensate, resulting in even more user connections becoming linkable. Now, this isn't the whole story. Maybe there are really good security improvements that can be had by not fetching the whole site over a single connection -- see e.g. item #1 on https://tor.eff.org/volunteer#Research or (a more tenuous connection) http://freehaven.net/anonbib/#pet05-serjantov But on the third hand, see http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#SplitStreams Until somebody works through both the security issues and the performance issues in a convincing way, we will likely just stick with the current behavior. --Roger
Re: Need to run UDP & ICMP through Tor
On Sat, Sep 22, 2007 at 01:21:59PM -0400, misc wrote: > Is there a way to torrify UDP (I'm not talking about DNS) and ICMP? > > For example how can I ping somebody through Tor? No. At least, not in 2007. http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP --Roger
Need to run UDP & ICMP through Tor
Is there a way to torrify UDP (I'm not talking about DNS) and ICMP? For example how can I ping somebody through Tor?
Re: About HTTP 1.1 Cache
> That's why Privoxy can randomize the time within ranges that > are unlikely to cause revalidation failures: > http://www.privoxy.org/user-manual/actions-file.html#HIDE-IF-MODIFIED-SINCE > http://www.privoxy.org/user-manual/actions-file.html#OVERWRITE-LAST-MODIFIED I believe you're referring to the following functionality: > The "randomize" option overwrites the value of the > "Last-Modified:" header with a randomly chosen time between the > original value and the current time. Most servers treat Last-Modified values as opaque validators -- i.e. ``IMS: foo'' matches if the modification date is not exactly foo, rather than matching if the modification date is more recent than foo. Hence, in practice the randomize setting will bust the cache. (The reason for that is that this approach is more reliable in the presence of broken clocks somewhere in the universe.) > Therefore it's questionable if anyone is going to bother. We're in violent agreement. Juliusz
Re: [Polipo-users] Reminder: running Polipo with Tor, no need to mail me
> On Sat, Sep 22, 2007 at 05:11:57PM +0200, [EMAIL PROTECTED] wrote 1.3K bytes > in 35 lines about: > > For Polipo 1.0.3, I'll include a config.tor for the lazy people. Point taken. Patches welcome. Juliusz
Re: [Polipo-users] Reminder: running Polipo with Tor, no need to mail me
On Sat, Sep 22, 2007 at 05:11:57PM +0200, [EMAIL PROTECTED] wrote 1.3K bytes in 35 lines about: For Polipo 1.0.3, I'll include a config.tor for the lazy people. -- Andrew
Re: Load Balancing
> - privoxy will use new streams on the same circuit for each of the images > - polipo will generally pipeline everything over the same stream Not quite. Polipo will try to use up to n simultaneous connections to a given server, where n is - 2 for a server that can do pipelining; - 4 for a server that can do persistent requests but not pipelining; - 8 for a server that cannot do persistent requests. These magic constants are configurable. Ideally, Polipo should choose the number of simultaneous connections depending on an estimate of average queue length, but I haven't thought about it seriously yet. > I believe this results in a perceptible performance improvement for general > browsing. I think so too, but some people disagree. Since I don't want to get into this discussion again, I refer you to the following friendly flamewar. (Note that while the tone was not always as polite as it should have been, Fabian and I live in good friendship and mutual respect.) Me: http://archives.seul.org/or/talk/Apr-2007/msg00056.html Fabian Keil: http://archives.seul.org/or/talk/Apr-2007/msg00063.html Me: http://archives.seul.org/or/talk/Apr-2007/msg00066.html Me clarifying: http://archives.seul.org/or/talk/Apr-2007/msg00069.html You may also find this paper interesting: http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html Juliusz
Reminder: running Polipo with Tor, no need to mail me
Dear all, In an attempt to reduce the amount of queries I receive by personal mail, please make a note of the following. Running Polipo with Tor is described in excruciating detail on http://www.pps.jussieu.fr/~jch/software/polipo/tor.html The Polipo manual is included in the Polipo distribution, and is also available online on http://www.pps.jussieu.fr/~jch/software/polipo/manual/ There is also a detailed FAQ on http://www.pps.jussieu.fr/~jch/software/polipo/faq.html If the above do not answer your question, please feel free to ask on either the polipo-users or the or-talk list, both of which are full of knowledgeable people and both of which I try to monitor regularly. Do not contact me by private mail, unless you have a good reason. If you do, I'll probably ask you to repeat your query on the mailing list. Juliusz
How-To Torify full TCP Host connection / full TCP subnet connection
Hello to all, i'm spartacus the owner of spartacus tor server. I'm running the tor server mainly for studing this new protocol I'm quite new in this tecnology, i ask you to understand How-To: 1) Torify a full PC. I have a pc : 192.168.33.33, in the net 192.168.33.0/24, in this net there is a tor server 192.168.33.148 and a default gateway 192.168.33.1. I wont to torify all TCP connection from 192.168.33.33 to *.*.*.* net :) 2) Torify a sunbet. I have many PC 192.168.34.x , in the net 192.168.34.0/24, outside the net is a tor server 192.168.33.148 and a default gateway 192.168.33.1. I wont to torify all TCP connection from 192.168.34.x to *.*.*.* net :) Where i can put a sniffer to controll if the traffic is correctly torrified? Thanks for your support.
Re: Load Balancing
On Fri, 21 Sep 2007 15:06:39 -0700 "Michael_google gmail_Gersten" <[EMAIL PROTECTED]> wrote: >On 9/21/07, Alexander W. Janssen <[EMAIL PROTECTED]> wrote: >> On 9/21/07, Nick Mathewson <[EMAIL PROTECTED]> wrote: >> > Short answer: Tor tries to group many streams on a single circuit. If >> > we didn't, that would be way too much PK. >> >> Means, if the browser opens up 6 instances to grab stuff from a site, >> Tor consolidates all requests into a single circuit? >> >> Makes sense from a performance point of view. >> >> > yrs, >> > Nick Mathewson >> >> Alex. > >If you have a web page with 30 sub-fetches (images, style sheets, >script files, etc), then they will all fetch over a single circuit. Unless the circuit becomes "old" or is closed by a server going down, of course. Also, there is at least the possibility, however unlikely, that one or more of the subordinate fetches will take a different circuit because of some peculiarity in the relationship between the page and the item on the page, e.g., the page is on a non-tor-related web server and the item on the page is on a web server "near" a tor server allowing local exits to that web server. > >It does NOT make sense from a performance point of view. Since >everything will be encrypted, regardless of which circuit it takes, >there is no performance impact. On modern CPUs, the encryption-decryption workload has to be a minor factor in the performance of a circuit. That is why NumCPUs > 1 makes so little difference. Performance for most circuits will be limited by the network performance characteristics of their various servers and the Internet paths currently connecting them. > >The question of network efficiency is an interesting one. A single >circuit will be slower than many circuits. However, each new circuit >will start off slower (TCP takes time to get up to speed). Many >established circuits will be faster than one established circuit. [1] > >The question of anonymity is more interesting. When I asked on the >development list, I was told that using a single circuit rather than >many circuits helped users to remain anonymous. I didn't understand >the explanation, so I can't repeat it; I trust that the people who >have studied that more than I have know what they are talking about. > >[1] This is more true statistically than absolutely. If you have many >circuits, some will be fast, and some slow. Rotating your usage, >concentrating on those circuits with the smallest queue, will send >more TCP channels over faster Tor circuits. However, with many >circuits, you pretty much guarantee that one will be slow. With a >single circuit, you have the "all eggs in one basket" case, and you >may have a very slow connection. > The above [1] seems correct as far as it goes, but it needs a bit of tweaking because separate circuits originating in a particular client are have a chance, and in the case of entry guard usage, a very high chance, of sharing some tor server interconnections. Tor servers normally have no more than one open socket at a time to any other given tor server's ORPort. That socket may carry many circuit segments from different circuits with no way to know, from the point of view of the tor server on either end of the socket, whether any of those circuit segments originate from the same client. Each of those circuit segments may have many tunneled TCP streams traversing it. Now back to those entry guards. A client using entry guards picks a few and connects sockets to their ORPorts. As it builds circuits, all have one of those entry guards as their first hop. Therefore *all* circuits go through one of those few (NumEntryGuards) sockets, and thus *all* tunneled TCP streams also go through those few entry guards. The default value of NumEntryGuards is 3, so in that case, all circuits and all TCP streams tunneled through them that originate from that user's browser will be split across no more than three distinct first hops and are thus in competition with each other for bandwidth to whichever entry guard(s) is(are) in use and for bandwidth out the other side(s) of that(those) entry guard(s). This situation might also occur when UseEntryGuards = 0 because it is also the same situation occurring whenever more than one tunneled TCP stream takes a path sharing, at any hop, the same tor server as another tunneled TCP stream. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * **
Re: Load Balancing
On Friday 21 September 2007 19:34:09 Alexander W. Janssen wrote: > On 9/21/07, Arrakis <[EMAIL PROTECTED]> wrote: > > Hey guys, quick question. > > > > If I have Tor process running, and request a url that has 10 images to > > load from the same domain, do all the requests go through the same > > circuit, or does the tor process split up the requests across all the > > circuits? > > Interesting question. From what I understood a new circuit is created > for every TCP-connection. If your browser grabs, for instance, 6 > images at the same time (6 loading instances == connections), Tor > should open 6 different circuits. > > However, considering your question... It doesn't sound too efficient > to me... The slides say "If the user wants to access a different site, > Alice's Tor client selects a different path." > I'm curious how strict I should read that... > > Site vs. TCP-connections? > > Alex. > The original question is answered later in the thread, but there is an interesting distinction between polipo and privoxy in the way this situation is handled: - privoxy will use new streams on the same circuit for each of the images - polipo will generally pipeline everything over the same stream I believe this results in a perceptible performance improvement for general browsing. Someone please correct me if I've got this wrong, because I'm just working from observation. -- Browse Anonymously Anywhere - http://anonymityanywhere.com TorK- KDE Anonymity Manager - http://tork.sf.net KlamAV - KDE Anti-Virus- http://www.klamav.net
Re: About HTTP 1.1 Cache
"http://www.pas-world.com"; <[EMAIL PROTECTED]> wrote: > What about If-Modified-Since header with time now? The website can know > the las visit, time and the pages of browser with a database. That's why Privoxy can randomize the time within ranges that are unlikely to cause revalidation failures: http://www.privoxy.org/user-manual/actions-file.html#HIDE-IF-MODIFIED-SINCE http://www.privoxy.org/user-manual/actions-file.html#OVERWRITE-LAST-MODIFIED Note however, that using If-Modified-Since as Cookie replacement is a lot more work than simply embedding URLs with session info. Therefore it's questionable if anyone is going to bother. Especially since the latter can't be easily fooled without purging the cache. Fabian signature.asc Description: PGP signature
Re: Load Balancing
"Michael_google gmail_Gersten" <[EMAIL PROTECTED]> wrote: > On 9/21/07, Alexander W. Janssen <[EMAIL PROTECTED]> wrote: > > On 9/21/07, Nick Mathewson <[EMAIL PROTECTED]> wrote: > > > Short answer: Tor tries to group many streams on a single circuit. If > > > we didn't, that would be way too much PK. > > > > Means, if the browser opens up 6 instances to grab stuff from a site, > > Tor consolidates all requests into a single circuit? > > > > Makes sense from a performance point of view. > If you have a web page with 30 sub-fetches (images, style sheets, > script files, etc), then they will all fetch over a single circuit. That's likely, but not guaranteed. Circuits don't last forever. Fabian signature.asc Description: PGP signature
