Re: Country-code exit broken in 0.2.2.21-alpha?
On Sun, Jan 23, 2011 at 2:42 PM, Geoff Down geoffd...@fastmail.net wrote:
Hi list,
I know for a fact that there is at least one GB exit running, but
ExitNodes {gb}
StrictNodes 1
no longer works - no circuits get built.
Tor 0.2.2.21-alpha (git-5f63f0d6312d9f0d) PPC OSX10.3.9
No flags next to the relays in Vidalia either - I thought that was due
to be fixed.
I just current maint-0.2.2 from the command line and it built circuits okay with
./src/or/tor -geoipfile ./src/config/geoip -exitnodes '{gb}' -strictnodes 1
Could there be a vidalia issue here? Could some other option be
interfering? Could you have a missing geoip file somehow?
--
Nick
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Double log entries?
On Wed, Jan 5, 2011 at 9:32 PM, Geoff Down geoffd...@fastmail.net wrote: Hi All, Happy New Year. I have double entries, including the timestamp, in my Notice-level Tor logs. I think it started when I sent a SIGHUP. lsof shows two Write file descriptors fwiw. This is Tor 0.2.2.15-alpha OSX PPC, Vidalia is not running. Any ideas? Really dumb question: is it possible that you the log configured twice in your torrc? -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Key length and PK algorithm of TOR
On Fri, Dec 31, 2010 at 5:10 PM, and...@torproject.org wrote: On Fri, Dec 31, 2010 at 09:21:53PM +0100, canconsult...@web.de wrote 0.6K bytes in 20 lines about: : 1) is there a specific reason why TOR does use RSA with : a keylength of only 1024 Bit? Start here, http://archives.seul.org/or/dev/Dec-2010/msg00012.html. : 2) is there a specific reason why TOR does not use ECC, : which is more secure (with reasonable curve parameters and same : key length like RSA) *and* uses less or, depending on the : ECC algorithm, at least not significantly more CPU cycles than RSA? A quick answer is most ECC implementations we may want use are patent encumbered. However, Nick or Roger will have a better answer. Well, there are at least a number of respectable people who think that some ECC can be used in a non-patent-infringing way. Certicom seems to be taking the position that their patents cover all ECC usage -- and why wouldn't they? -- but others seem to think that ECC using the P groups can be done safely, and DJB of course is quite confident in Curve25519. But to answer your questions, the main reason Tor doesn't use ECC now (and that its RSA keys are 1024 bits except for authority keys) is that back when we designed the relevant parts of the current Tor protocol in 2003-2004, RSA-1024 seemed like a reasonably good idea to us. We figured we could change it pretty easily when it started showing its age, but as [1] should show, it might take a fair bit of engineering to get cipher migration right. There's a related question that people sometimes ask: Why didn't you make it so Tor could support an arbitrarily large array of cipher combinations? Three main reasons. First, we were worried about the ciphersuite fingerprinting attacks that plague the cpunk remailer design. If an anonymity design forces users to pick from multiple ciphers, users will stand apart from one another based on their cipher choice. (There's actually an even more subtle argument here; we wrote a paper about it. [2]) Second, we were worried about protocol downgrade attacks and didn't want to have to consider a secure protocol negotiation scheme on top of everything else we were doing. Third, we really wanted to get a working Tor completed in a reasonable amount of time. Robert Ransom and I (and others) are trying to start off a discussion on or-dev about migrating Tor to work with longer keys and faster ciphers; see [1] and [3] for more info there. [1] http://archives.seul.org/or/dev/Dec-2010/msg00012.html [2] http://weis2006.econinfosec.org/docs/41.pdf [3] http://archives.seul.org/or/dev/Dec-2010/msg00013.html peace happy new year, -- Nick -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: 27C3 on Tor
On Tue, Dec 28, 2010 at 8:27 PM, Roc Admin onionrou...@gmail.com wrote: This doesn't seem like much of a flaw as it is a design decision. See https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#Youshouldsendpaddingsoitsmoresecure. I'm not trying to dismiss the researcher but maybe someone can give some insight into how critical this is to the Tor project and what avenues for remediation there are if any. Anyone have a video of the presentation? From the wired.com article, this sounds _exactly_ like the old website fingerprinting attack, which has been known since 2002: http://freehaven.net/anonbib/#hintz02 It would be neat if somebody could send a pointer to the authors' actual results. -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor 0.2.1.26-1~~lenny+1: segfault with libcryto.so.0.9.8
On Fri, Nov 12, 2010 at 5:49 PM, Paul Menzel paulepan...@users.sourceforge.net wrote: Dear Tor folks, I noticed that Tor had crashed on my system. I am using Debian Lenny with Tor 0.2.1.26-1~~lenny+1. The only thing I could find out about this crash is the following line running `dmesg`. $ dmesg […] [Several of these Treason uncloaked messages as you can see some seconds before the crash. I obfuscated the IP addresses.] [3301769.746795] TCP: Treason uncloaked! Peer xxx.xxx.xxx.xxx:60659/42859 shrinks window 1343914705:1343916145. Repaired. [3413085.371871] TCP: Treason uncloaked! Peer yyy.yyy.yyy.yyy:19595/45969 shrinks window 2416591117:2416591857. Repaired. [3604257.970658] tor[22506]: segfault at 21d4fc5 ip 7f1e78ba4ea6 sp 41188920 error 4 in libcrypto.so.0.9.8[7f1e78b21000+172000] [3604257.970707] type=1701 audit(1289305397.030:2): auid=4294967295 uid=102 gid=104 ses=4294967295 pid=22506 comm=tor sig=11 So it could also be libcrypto is the culprit. `libssl0.9.8` is running with `0.9.8g-15+lenny8` as version. Is that a known problem? What other information can I provide to solve that? Unfortunately I have not found out how to reproduce it yet. Without more information, there's not much info to go on there to diagnose the problem. Generally, to debug a segfault, we need a stack trace. To get one of those, make sure you're running Tor with coredumps enabled, and use gdb to get a trace if Tor crashes again. There are some decent online docs on how to do this; a little searching should turn them up. (You can ignore the Treason Uncloaked! junk. That's the Linux kernel being overly dramatic about peers that don't do TCP windows right or something.) hth, -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: AdvTor
On Thu, Oct 7, 2010 at 4:32 AM, Anon Mus my.green.lant...@googlemail.com wrote: On Sun, Oct 3, 2010 at 2:05 PM, kalitnik...@privatdemail.net wrote: Hello everyone. I found a fork (?) of tor software with GUI named Advanced Tor. I was surprised of its features, but found just nothing about it in web, though it has opened source placed in sf.net. Have you people discussed it? Please give a link to discussion if yes. Otherwise you are welcome (if it won`t break any or-talk rules), especially I`d like to know if someone can get through the code to check it for backdoors or something like that. Description and source: http://nemesis.te-home.net/Projects/AdvTor.html http://sourceforge.net/projects/advtor/ http://nemesis.te-home.net/Projects/AdvTor.html When connecting to this site through Tor either I get a disconnect or a weird message saying I am connecting via a proxy which is changing my data. I have only once had an acutual web page to browse (right after it the first post to OR-TAlk). Is this a TOr problem (e.g. a ban by Tor exits) or a site problem? Not sure what your trouble is here, but Tor doesn't ban sites. I just tried connecting there, and it worked fine for me. yrs, -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Stop TOR from building circuits in the background?
On Wed, Oct 6, 2010 at 8:47 AM, Brian Johnson brian_john...@gmx.net wrote: Hello, I am using the -controlport Commands to build custom Circuits. My problem with this is that I cannot trust TOR to use these circuits. It keeps building new ones which were not requested by me via the command interface. I can drop all circuits, build 2 new ones, refresh the circuit list and there are more than 2. Can I deactivate this feature without recompiling? Keep reading control-spec.txt till you get to section 5.4. Look at the documentation for __LeaveStreamsUnattached and __DisablePredictedCircuits. You'll want both, and you'll need to use ATTACHSTREAM to attach streams yourself. peace, -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: tor and resolv.conf / ipv6
On Thu, Sep 2, 2010 at 12:10 PM, Udo van den Heuvel udo...@xs4all.nl wrote: On 2010-09-02 17:34, Udo van den Heuvel wrote: Tor chokes and stops when it finds ipv6 numbers in resolv.conf. Is this a known issue? Sadly, yeah. As a workaround, if you build Tor with Libevent 2.0.x, Tor will use Libevent's evdns code, rather than its own internal (and lagged-behind) implementation. Libevent 2.0's dns code knows how to handle IPv6 addresses for DNS servers. (You can't do this with older versions of Libevent, since until about Libevent 2.0, Tor required evdns features that Libevent didn't have.) As another workaround, you can specify an alternative resolv.conf file using the ServerDNSResolvConfFile command. As a real fix, there are a few possibilities. * Port the ipv6-resolver code over from Libevent 2. [Not going to happen in Tor 0.2.2.] * Re-port the entirety of evdns.c over from Libevent 2. [Definitely not going to happen in Tor 0.2.2] * Just wait until Libevent 2.0.x is ubiquitous. yrs, -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Vulnerability in OpenSSL 1.0.x Firefox 4 Silent Updates
On Wed, Aug 11, 2010 at 2:42 AM, whowatchesthewatcherswatc...@safe-mail.net wrote: Vulnerability in OpenSSL 1.0.x http://marc.info/?t=12811816911r=1w=2 http://archives.neohapsis.com/archives/fulldisclosure/2010-08/0085.html Tor server/client use vuln? Looking at the claims, it seems to only affect OpenSSL 1.0.0a and maybe 1.0.0. (I can reproduce it with 1.0.0.a, but not with 0.9.8x and earlier.) None of our binary packages ship with any version of OpenSSL 1.0.x (unless I'm missing something), so people using our binaries are probably safe. I'll ask around harder later today to make sure everything is in fact getting built in conformance with its instructions. If you're using a version of openssl 1.0.0a that comes with your operating system, with any luck your vendor will already have issued a patch. If not, there is an alleged patch posted in that thread at http://marc.info/?l=openssl-devm=128128256314328w=2 ; I haven't evaluated it, and it doesn't seem to have gotten merged into openssl proper yet, so you shouldn't apply it blindly. It looks safe to me, but what do I know? Personally, I'd think re-linking your Tor against a statically built 0.9.8o would probably be a better bet than rebuilding your vendor openssl. It's also possible (though not certain) that Tor could be unaffected. If you look at the code in question, it only seems to gets invoked for the elliptic-curve crypto case, which Tor doesn't use or enable. OTOH, I haven't checked carefully enough to be sure there's no way to force an openssl 1.0.0a server into that codepath if it doesn't have any elliptic curve stuff configured, so caution is still warranted. -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Why not TOR come up with an encryption system?
On Mon, Jun 7, 2010 at 6:03 AM, Sebastian Hahn m...@sebastianhahn.net wrote: On Mon, June 7, 2010 4:26 am, emigrant wrote: i mean apart from anonymity, can it have something to do the work of SSL? i mean for all connection. thanks a lot No, this is not possible. To do the work of SSL, you need a destination that supports encryption, and unfortunately many still don't support that. To be explicit about why: no encryption will actually work unless the final party receiving your connection has the ability to decrypt it to see what you said. This would mean that, even if Tor had a built-in end-to-end encryption tool, wouldn't do you any good on sites that didn't install the tool as well. And once we're requiring both sides of the communication to install extra software, we might as well just have both sides just support SSL and be done with it. (Personally, I think that our chances are better here if it _is_ SSL: it's easier to convince website operators to support https than it would be to convince them to run a special Tor decryptor, run as a hidden service, or whatever Tor-specific option we might imagine.) peace, -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor Problems on Korean Windows
On Tue, May 11, 2010 at 6:31 PM, Kees keesv...@gmail.com wrote: I recently installed tor on the windows machine of a Korean friend and it did not want to work. After a lot of messing about we worked out the the problem was his Korean user name in the path to the torrc file. Once we moved the torrc file to c:\program files\vidalia\tor and told vidalia we had done that, everything to started working. So it seems that either tor or vidalia chokes on unicode characters in the torrc path. I presume I should log this as a bug somewhere, but I am not entirely sure where. Hi! The bugtracker is at bugs.torproject.org. yrs, -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: messages indicate strange choice by tor
On Wed, Apr 14, 2010 at 10:02 AM, Scott Bennett benn...@cs.niu.edu wrote: I would be most interested in knowing the explanation for the decision that tor announced in the following pair of messages. Apr 14 08:55:50.861 [info] connection_or_group_set_badness(): Marking OR conn to 194.109.206.212:443 as too old for new circuits: (fd 7, 900 secs old). We have a better canonical one (fd 118; 2239 secs old). Apr 14 08:55:50.861 [info] run_connection_housekeeping(): Expiring non-used OR connection to fd 7 (194.109.206.212:443) [Too old]. Why is the younger connection too old, yet the much older connection is somehow better? Oops, just saw that nobody had answered this. That info message is a bit misleading; too old in the message should really be something more like unsuitable. For the full ugly details, check out connection_or_group_set_badness() and connection_or_is_better() in connection_or.c. Some reasons you might get that message is if the older connection is canonical and the new one isn't, or if the older one has circuits and the new one has gone 15 minutes but gotten no circuits. I'll fix that info message in 0.2.2.x. yrs, -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Bug in .tmp file handling
On Sat, Mar 20, 2010 at 1:45 PM, grarpamp grarp...@gmail.com wrote: Note the double .tmp file extension. Added as bug 1376. Thanks! -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Advertising multiple ORPorts at once
On Fri, Mar 19, 2010 at 11:26 AM, hiro 23h...@googlemail.com wrote: Hi, I've been skimming over the gsoc ideas. The Tor 0.2.1.x series makes significant improvements in resisting national and organizational censorship. But Tor still needs better mechanisms for some parts of its anti-censorship design. For example, current Tors can only listen on a single address/port combination at a time. How exactly does this improve anonymity? It helps with anti-censorship, not anonymity per se (afaict). The idea is that many hosts have more than one address, and nearly all can listen on multiple ports. Actually using this ability would allow a bridge to actually accept connections at all its addresses (in the first case) and help defeat naive port-blocking approaches (in the second). It's not exactly cutting edge stuff, but every little bit can help here. yrs, -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: tor 0.2.1.24 crashes on Sparc-Solaris10
On Wed, Mar 10, 2010 at 3:47 PM, thomas.hluch...@netcologne.de wrote: Am Dienstag 09 März 2010 schrieb Roger Dingledine: On Tue, Mar 09, 2010 at 08:23:30PM +0100, thomas.hluch...@netcologne.de wrote: When starting tor it comes up but crashes within one minute. Try these: http://freehaven.net/~arma/tor-0.2.1.24-dev.tar.gz http://freehaven.net/~arma/tor-0.2.1.24-dev.tar.gz.asc Unfortunately this didnt help. But I succeeded in another way meanwhile: The crashing tor executables were built with gcc. The one who works right now, is from Your dev tarball, but built with Suns cc plus an interesting CFLAG. I found some info in the net (http://developers.sun.com/solaris/articles/manage_core_dump.html): The Sun Studio C/C++ compiler has the -xmemalign option, which can be used to adjust the behavior of the UltraSPARC CPU when there are unaligned memory addresses that can be determined at compile time. The -xmemalign option causes the compiler to generate additional load/store instructions for unaligned memory access. However, the -xmemalign option cannot handle unaligned memory access during runtime. If unaligned memory access happens during runtime, the developer needs to change the source code. It would still help a lot if you could get a stack trace to find out where the unaligned memory access happens. We try to only do aligned memory access in our code; if there's somewhere where we're doing unaligned access, I want to find it and fix it. yrs, -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: tor 0.2.1.24 crashes on Sparc-Solaris10
On Tue, Mar 9, 2010 at 2:23 PM, thomas.hluch...@netcologne.de wrote: [...] Any ideas, any help? Can you get a stack trace? That's usually the best way to start debugging a crash. -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: getinfo circuit-status
On Sat, Feb 13, 2010 at 3:21 PM, Nico Weinreich i...@web-unity.de wrote:
Hi,
when interacting with tor control I can get the circuit with command
getinfo circuit-status. What's a bit confusing for me, there are more than
one circuits:
getinfo circuit-status
250+circuit-status=
51 BUILT rueckgrat,myrnaloy,$2DDAC53D4E7A556483ACE6859A57A63849F2C4F6
PURPOSE=GENERAL
50 BUILT Freedom,nixnix,$4744AD962D32A11CD7CF4513617FAC33B339806B
PURPOSE=GENERAL
15 BUILT HW2,$4F0826FA4C325C3CAA0054A6E023E566302C20C7,RainCloud
PURPOSE=GENERAL
14 BUILT Freedom,SuperDave,bp1 PURPOSE=GENERAL
So I have two questions:
-which circuit does tor use (is it alway the circuit with the highest
number?)
No; it's the one that's considered best for the particular stream.
The general rule is that first, a circuit must be appropriate for the
stream (the exit policy must be compatible, the capacity must be
adequate, the nodes must be stable enough, etc). Second, the circuit
must not be too dirty (a circuit becomes 'dirty' the first time it's
used; once it's been dirty for CircuitMaxDirtiness seconds, it
shouldn't be used for attaching new streams). Third, a less dirty
circuit is treated as better than a more dirty circuit.
{This is based on re-reading circuit_get_best in circuituse.c.}
-is there a way to get this nodes always as fingerprint (for example, there
are many nodes with name idideditheconfig and how do I know which one is
it when the node is listed in plain text?)
Yes; have your controller say USEFEATURE VERBOSE_NAMES early on.
(VERBOSE_NAMES is documented in section 3.19 of control-spec.txt; the
LongName format is uses is explained in section 2.4.)
HTH,
--
Nick
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: getinfo circuit-status
On Mon, Feb 15, 2010 at 2:17 PM, Nico Weinreich i...@web-unity.de wrote: [...] OK, thanks for this very detailed explaination. But is there a way to get (before or after a HTTP request) the circuit which will be (or was) used? If you watch for STREAM events, you'll learn which streams get attached to which circuits. -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Path-spec - fast circuits
2010/2/12 ilter yüksel ilteryuk...@gmail.com: Hello, For exit router selection path-spec says that; For circuits that do not need to be fast, when choosing among multiple candidates for a path element, we choose randomly. For fast circuits, we pick a given router as an exit with probability proportional to its bandwidth. Could anybody explain why Tor pick exit router with probability proportional to its bandwidth only for fast circuits? As far as i know Tor uses this technique for load-balance. But why it uses this technique only for fast circuits? First of all, Fast circuits are a bit misnamed as used in path-spec.txt. Basically, fast means bandwidth-sensitive. The only ones that aren't don't need to be fast in this sense are ones that are going to be used only for a tiny amount of traffic. That said, I think the statement in path-spec.txt may be poor. It probably makes sense to weight all choices by bandwidth, now that bandwidth is measured rather than just being self-advertised. To see what the code is actually doing, the string to search for is need_capacity or NEED_CAPACITY. The most interesting layer to look for this is at is where it's passed as a flag to circuit_launch_by_router() or circuit_launch_by_extend_info(). -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Nodes selection algorithm
On Mon, Feb 8, 2010 at 10:02 AM, Mansur Marvanov nanorobo...@gmail.com wrote: Oh, I got the meaning of exit-nodes: it's for selection the preferred country as exit of your route. But still the question is How Tor choose the route? The best specification of this is in the path-spec.txt document shipped with the Tor distribution. It's not complete, but it's an okay start. There are also some relevant proposals in doc/spec/proposals at http://gitweb.torproject.org//tor.git?a=tree;f=doc/spec/proposals *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: What means that log record?
On Mon, Feb 8, 2010 at 12:27 AM, Soviet Union unionsovietun...@aol.com wrote: I have some the next recored in logs of the Tor: [warn] Bug: Duplicate call to connection_mark_for_close at connection.c:1175 (first at connection_edge.c:1618) What mean that bug and what I need to do? (or not I need to do anythin?) * It means that one part of the code said close connection X when you get around to it! and another part of the code also said close connection X when you get around to it! We try not to allow this in the code base, since a connection that's marked to be closed shouldn't really be used in a way that would make us want to close it again. This isn't a problem for you, since the code catches it and tries to handle it gracefully. It is a problem for the developers, though. What version of Tor are you seeing these messages from? -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Bringing back Tor on the iPhone - take 2
On Tue, Feb 2, 2010 at 8:13 AM, Marco Bonetti marco.bone...@slackware.it wrote: [...] 1) strictly related to tor: I build the latest stable release *WITHOUT* the --enable-iphone switch. As I can understand from the post linked above, that option will jusr add some compiler flags needed only by older version of the iphone toolchain/firmware and I think that probably they could be removed as no longer necessary. Does anyone know something more on that patch? That matches with my impressions of it. All it does is define __DARWIN_UNIX03 and IPHONE. The only place in Tor that looks at IPHONE is set_max_file_descriptors, where instead of defaulting to asking for 15000 connections, it only asks for . If the define and the fd limit change aren't needed any more, let's kill them. -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Memory usage on relays
On Tue, Jan 19, 2010 at 4:18 AM, Olaf Selke olaf.se...@blutmagie.de wrote: Nn6eumtr wrote: Binaries are staticly linked so that someone can't substitute a replacement library. Otherwise you can replace the library or set LDPRELOAD to implement a variety of attacks. can you give an example what's wrong with LD_PRELOAD/foo/bar/libssl.so /foo/bar/libcrypto.so in /etc/init.d/tor? That's how I enable special openssl versions on Debian. The failure mode is if you somehow wind up in a position where an adversary is in control of your environment; they could set LD_PRELOAD or LD_PATH to whatever they wanted. Personally, I'm not convinced that this is a reason not to dynamically link. Most attacks that would give somebody write access to your environment would let them subvert your system in ways that don't require dynamic linking. (That is, If the attacker can run arbitrary shell commands, put stuff in your ~/.profile, or mess with your shell process's memory, then they're in a great position whether your binaries are static or not.) I'm not alone in thinking this: there are some pretty paranoid applications out there (gnupg and openssh for example) that are happy to use the dynamic linker. yrs, -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Memory usage on relays
On Sun, Jan 17, 2010 at 11:29 PM, John Brooks spec...@dereferenced.net wrote: [...] As a vaguely related sidenote, is it intentional that openssl is statically linked? I would expect that Tor more than anything would want to benefit from security updates as quickly as possible, and most package managers / people won't rebuild it after an openssl update. Seems a bit dangerous. I was able to confirm that I was running with the right version, though, by adding the following right under Tor's version notice: Tor links against openssl dynamically for me, at least. Let us know if there's some more magic we need to do in src/or/Makefile.am to make it dynamically linke for others. I'm not sure openssl builds shared libraries by default, though: could that be the problem. -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Memory usage on relays
On Sun, Jan 17, 2010 at 9:36 PM, Roger Dingledine a...@mit.edu wrote: On Sun, Jan 17, 2010 at 06:41:03PM -0700, John Brooks wrote: I run a reasonably fast (500KB/s) node with Guard+Fast+Stable, so it's a popular destination. It runs at bandwidth capacity at all times. The only problem with this is the massive memory usage that results; at the moment, Tor has 748MB res usage, with almost 7 days of uptime. Generally it escalates at a rate of 100-200MB per day after a restart, and tops out around this number. My understanding is that most of that memory usage is related to the open connections; socket buffers, SSL buffers, etc. At the moment (according to /proc/x/fd), Tor has 5,364 open connections. Nick wrote an OpenSSL patch to not waste so much memory in its internal buffers. See item #3 on http://archives.seul.org/or/dev/Jun-2008/msg1.html I ran a super-fast Tor relay recently that held 15000 TLS connections open. That's 550MB of ram wasted inside openssl. That said, I don't know what the current state of the patch is, or where you can get a copy. Nick? It's in recent versions of OpenSSL (recent as in the 1.0.0 beta versions.) If you would rather try patching an older version of OpenSSL yourself, try out http://freehaven.net/~nickm/openssl_mem/openssl-mem-patch-v17.txt I have no idea whether it applies cleanly (or at all) to older versions. hth, -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Failed to decode requested authority digest
Quoth Nick Mathewson ni...@torproject.org, on 2010-01-14 21:49:33 -0500: Nevermore! Jan 12 08:57:59.119 [warn] Failed to decode requested authority digest 14C131%2027B6B5%20585769%2081349F%20E2A2AF%20E8A9C4. Jan 14 11:40:05.641 [warn] Failed to decode requested authority digest 14C131%2027B6B5%20585769%2081349F%20E2A2AF%20E8A9C4. This looks like some kind of broken client to me. =A0Look at all those %20s in the string: that looks like http encoding of a space ( ) character, so somebody's program is requesting 14C131 27B6B5 585769 81349F E2A2AF E8A9C4 with the spaces HTTP-encoded. =A0Unless I'm mistaken, the proper format is using + signs, not spaces. If you mean URI-encoded (or URL-encoded), which HTTP uses, then %20 is a valid encoding of a 0x20 (ASCII space) character. =A0+ is a secondary convention that's used in query strings only, which can also mean a space character. =A0Does the Tor directory request protocol specify something else? For this URL, dir-spec.txt specifies: http://hostname/tor/status-vote/current/consensus/F1+F2+F3.z Where F1, F2, etc. are authority identity fingerprints the client trusts= . Servers will only return a consensus if more than half of the requested authorities have signed the document, otherwise a 404 error will be sent back. The fingerprints can be shortened to a length of any multiple of two, using only the leftmost part of the encoded fingerprint. Tor uses 3 bytes (6 hex characters) of the fingerprint. The last sentence should probably start The Tor client uses... The plus signs have been required as long as I can remember, though I agree that a more standards-friendly use of HTTP would accept any equivalent URI-encoded string. I'd welcome a patch or two to handle proper URI-encoding better, or alternatively a patch to dir-spec.txt to be more explicit about anything at all. The dir-spec.txt document from Tor 0.2.1.20 doesn't seem to be clear on how fp is interpreted in URIs. Agreed. The closest it comes is saying, ] http://hostname/tor/status-vote/next/fp.z ] where fp is the fingerprint of the other authority's identity key. From this, the reader is presumably meant to infer that fp means an arbitrary-length hexadecimal string, with current lengths of 160 bits (or 20 bytes, or 40 hex characters) , encoding a SHA1 digest of the public identity key of the corresponding authority. If any reader really infers this... that's some reader! Somebody should clean this up. Let me know if anyone has got a patch I can apply here. --=20 Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Latest router selection algorithm
2010/1/10 ilter yüksel ilteryuk...@gmail.com: Hello, I'm searching latest router selection algorithm which implemented on Tor 0.2.1.21. I couldn't find spec. or proposal for it. Could you help me how i can find some docs about it? The best document is still path-spec.txt, though proposals 160 and 161 may be of interest. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Failed to decode requested authority digest
On Thu, Jan 14, 2010 at 9:12 AM, Olaf Selke olaf.se...@blutmagie.de wrote: Olaf Selke wrote: since a couple of days tor logs an error condition about every 32 hours. Even looking at the code I don't really understand the cause. Jan 07 00:56:46.100 [warn] Failed to decode requested authority digest 14C131%2027B6B5%20585769%2081349F%20E2A2AF%20E8A9C4. Jan 08 09:48:38.437 [warn] Failed to decode requested authority digest 14C131%2027B6B5%20585769%2081349F%20E2A2AF%20E8A9C4. Jan 09 17:35:39.847 [warn] Failed to decode requested authority digest 14C131%2027B6B5%20585769%2081349F%20E2A2AF%20E8A9C4. Jan 11 01:05:58.288 [warn] Failed to decode requested authority digest 14C131%2027B6B5%20585769%2081349F%20E2A2AF%20E8A9C4. Hi folks, still getting these errors. Is there anybody out there knowing what this means? Jan 12 08:57:59.119 [warn] Failed to decode requested authority digest 14C131%2027B6B5%20585769%2081349F%20E2A2AF%20E8A9C4. Jan 14 11:40:05.641 [warn] Failed to decode requested authority digest 14C131%2027B6B5%20585769%2081349F%20E2A2AF%20E8A9C4. This looks like some kind of broken client to me. Look at all those %20s in the string: that looks like http encoding of a space ( ) character, so somebody's program is requesting 14C131 27B6B5 585769 81349F E2A2AF E8A9C4 with the spaces HTTP-encoded. Unless I'm mistaken, the proper format is using + signs, not spaces. It's also possible that they've got an HTTP proxy that is re-encoding their request for some reason. Either way, it's nothing to worry about on your side. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: TLS Man-In-The-Middle Vulnerability
On Wed, Nov 11, 2009 at 12:59:21PM -0500, Andrew S. Lists wrote: On 11/05/09 15:52, Nick Mathewson wrote: On Thu, Nov 05, 2009 at 02:10:00PM -0500, Marcus Griep wrote: Don't know if any one else has seen or taken a look at this. I don't know if this affects Tor, though I believe that we do use certificate renegotiation in the protocol, and that is the entry vector for this particular vulnerability: FWIW, this doesn't affect Tor. The problem here is not renegotiation per se; the problem is doing renegotiation, then acting as though data sent _before_ the renegotiation were authenticated with the rengotiated credentials. The Tor protocol isn't vulnerable here because 1) it doesn't allow data to be sent before the renegotiation step, and 2) it doesn't treat a renegotiation as authenticating previously exchanged data (because there isn't any). The vulnerability itself might not effect Tor, but the OpenSSL workaround for this vulnerability of disabling renegotiation by default in 0.9.8l [1] might not play nice with a Tor implementation. Indeed it will not. We have a fix in svn to make the 0.2.1.x and 0.2.2.x-alpha series both work correctly with OpenSSL 0.9.8l. With any luck, we should get releases out before too long. yrs, -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: TLS Man-In-The-Middle Vulnerability
On Thu, Nov 05, 2009 at 02:10:00PM -0500, Marcus Griep wrote: Don't know if any one else has seen or taken a look at this. I don't know if this affects Tor, though I believe that we do use certificate renegotiation in the protocol, and that is the entry vector for this particular vulnerability: FWIW, this doesn't affect Tor. The problem here is not renegotiation per se; the problem is doing renegotiation, then acting as though data sent _before_ the renegotiation were authenticated with the rengotiated credentials. The Tor protocol isn't vulnerable here because 1) it doesn't allow data to be sent before the renegotiation step, and 2) it doesn't treat a renegotiation as authenticating previously exchanged data (because there isn't any). Browser users, though, should watch out--especially if you use client certificates for anything. yrs, -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: 0.2.2.5-alpha doesn't know how to make libtor.a
On Sun, Oct 18, 2009 at 10:40:44AM -0500, Scott Bennett wrote: After running './configure CFLAGS=-march=prescott', a 'make' in the top (tor-0.2.2.5-alpha) directory did the following. I can't reproduce this; can you say more about your toolchain? What OS are you getting this on? Whose make are you using, and what version? If it isn't gmake, does trying gmake[*] cause the problem to go away? Does anything happen if you edit src/or/Makefile.in to replace every reference to ./libtor.a with one to libtor.a , then run configure again? [*] It wasn't our intention to require gmake; but learning that we broke non-gmake builds would be a good step to diagnosing what's wrong. peace, -- Nick *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Random chaff [was: more work for Grobbages]
On Fri, Sep 18, 2009 at 10:19:17PM -0400, Ted Smith wrote: On Fri, 2009-09-18 at 04:25 -0400, grarpamp wrote: Nodes usually have a max bandwitch set. Nodes often comsume less than this. All node to node traffic is encrypted. Perhaps implement a random stream generator that only runs when it or its chosen path has free bandwidth, tags its traffic as chaff, pipes it through some number of nodes, or if it has idle neighbors, and ultimtely sink it somewhere. It would be even harder to follow an actual client dl/ul stream if things were maybe udp with the stream reassembly info inside each onion wrapped cell. Or something like that. No doubt this is old ideas. Indeed it is, and it's my understanding that this doesn't really work. More astute minds than I can explain in full, but you can render this sort of safeguard useless quite easily. The issue with padding isn't that it doesn't work at all, but that it doesn't work well enough to do any good. Last I checked, the state of the art in low-volume padding could slow down correlation attacks by 10-50%, depending on how you're counting. This sounds good until you think about how fast correlation attacks actually are. If a correlating attacker (one watching both ends of the communication) needs only a second of traffic to link sender and receiver, then forcing him to collect an extra half-second of traffic doesn't actually help the user very much, assuming that the user intends to use Tor for more than a second and a half. What would need to change for padding to become useful? If it turns out that correlation attacks are far more difficult than the research community thinks, or if somebody comes up with a padding approach that actually delays correlation enough[**], I think we should come back to the question. [*] You can do high-cost methods that defeat correlation[***] pretty easily: constant-rate traffic is one of them. There's a FAQ entry about why constant-rate traffic probably won't work in the wild: http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#YouShouldPad [**] What's enough? I'd say the lifetime of a circuit, but I might be wrong. [***] But you'd still need to worry about active attacks in this case. peace, -- Nick
Re: unable to submit bug report
On Fri, Jun 05, 2009 at 02:41:53AM -0500, Scott Bennett wrote: On Fri, 05 Jun 2009 00:45:11 -0600 Jon scr...@nonvocalscream.com wrote: Scott Bennett wrote: Well, I *intended* to submit a bug report, but appear to be unable to log into the bugs.torproject.org web site to do so. I tried all sorts of things, including temporarily enabling JavaScript, which I really hate to do. If there is someone willing to submit the bug report for me, please let me know where to send the information. Thanks! You can send it to me. I've also included my PGP for your use if you so desire. Thanks, Jon. I'll put the material together and send it to you as quickly as I can. It will be plaintext, though. I haven't used PGP in well over a decade. Thank you so much for the stack traces! I have found a bug that I think might have caused this. (It's a little hard to tell for sure, because a bunch of functions got inlined.) Can you try this patch (also uploaded to flyspray)? diff --git a/src/or/policies.c b/src/or/policies.c index cb914d1..d55e86c 100644 --- a/src/or/policies.c +++ b/src/or/policies.c @@ -411,6 +411,7 @@ load_policy_from_option(config_line_t *config, smartlist_t **policy, memcpy(newp, n, sizeof(newp)); newp.prt_min = 1; newp.prt_max = 65535; +newp.is_canonical = 0; c = addr_policy_get_canonical_entry(newp); SMARTLIST_REPLACE_CURRENT(*policy, n, c); addr_policy_free(n); (Also, when we next switch bugtrackers, we should probably switch to one with an email gateway that works.) -- Nick
The Git conversion is done.
Tor is now in Git. The repository is at git://git.freehaven.net/git/tor.git There is also a historical-interest repository at git://git.freehaven.net/git/tor-history.git It has all the obsolete branches that we would never have put into svn in the first place if we had been working with a DVCS. [*] I've revised our internal Git Howto document a bit, with help from Marcus Griep. It might be a good starting point if you're new to Git: http://git.torproject.org/checkout/githax/master/doc/Howto.txt Happy hacking, -- Nick
Re: The Git conversion is done.
On Thu, Apr 30, 2009 at 12:57:30AM -0400, Nick Mathewson wrote: Tor is now in Git. The repository is at git://git.freehaven.net/git/tor.git There is also a historical-interest repository at git://git.freehaven.net/git/tor-history.git ARGH. That should be git.torproject.org, not git.freehaven.net. I have had a very long day.
Be ready: We're switching version control systems
Hello, everyone! Sometime in the next week or two, I am planning to move the repository for Tor software from Subversion to Git. This will only affect the Tor program itself -- other software in the Tor Project's Subversion repository will stay where it is for now. WHAT DOES THAT MEAN? When we develop software, we use a tool called a version control system to keep track of all of the changes we have made to it. Right now, we use Subversion, which is a pretty conservative centralized version control design: it manages everything in a big repository on our Subversion server. We're switching to Git, which is a decentralized version control system (DVCS): it allows for many repositories existing in parallel on different computers. For more info on Git and its advantages, see http://git-scm.com/ . We're mainly switching for: - Better support for branch merging. - Better support for distributed collaboration. - Better support for offline development. - Better support for security fix development. - Cryptographic confirmation of repository integrity. NOTES: - Yes, we'll back up before we start. - No, I don't know which day the switch will happen on yet. - No, the website is not moving out of svn. - Yes, this might be a good time to think about the story of the bike shed. [http://www.bikeshed.com/] HOW DOES THIS AFFECT YOU? == If you download Tor as a package It doesn't affect you at all, except inasmuch as it helps us develop Tor more effectively and get you better work faster. == If you have been tracking Tor from subversion, but not changing it Instead of checking out the repository using svn checkout, you'll clone it out with git clone. Instead of saying svn update to see the latest version, you'll say git pull. == If you have been writing patches for Tor against subversion, and mailing them in. As above, you'll need to use git to get the latest development version, not subversion. If you do your work on a local git branch, though, you have a better ability to make sure that your patches form a logical sequence, and that they apply cleanly against the latest Tor before you send them in. Of course, you can still just do your patches against a working copy, use git diff to generate a patch, and email it in. Just because you have support for local branches and versioning doesn't mean you need to use it. We'll be glad to work with people on the mailing lists and the IRC channels to help folks transition along with us. I'll be sending out links to more detailed instructions as the transition occurs. For more reading on Git, see: The Git Tutorial http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html http://www.kernel.org/pub/software/scm/git/docs/gittutorial-2.html Git for Computer scientists http://eagain.net/articles/git-for-computer-scientists/ The Everyday Git quick-reference: http://www.kernel.org/pub/software/scm/git/docs/everyday.html Git for SVN users: http://www.gnome.org/~newren/eg/git-for-svn-users.html Two very opinionated Google Tech Talks talks about Git: Randal Schwartz: http://video.google.com/videoplay?docid=-352944619245780 Linus Torvalds http://www.youtube.com/watch?v=4XpnKHJAok8 Our handy repository of (supposedly) useful Git tools. git://git.torproject.org/git/githax See in particular the documentation on using Git with our Thandy project; the instructions for Tor should be similar. http://git.torproject.org/checkout/githax/master/doc/Howto-thandy.txt And of course, the delightful Git Manual: http://www.kernel.org/pub/software/scm/git/docs/user-manual.html yrs, -- Nick Mathewson
Re: Segfaults on tor-0.2.12-alpha and tor-0.2.0.34
On Sat, Feb 21, 2009 at 11:12:35AM -0800, Phil wrote: This is driving me nuts. tor compiles fine but segfaults soon after starting. I have googled and found similar complaints but no solution. [...] How do I fix this? Can you get a stack trace? See https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#ReportBug if you're not sure how. -- Nick
Re: Excludenodes not considered?
On Sun, Feb 15, 2009 at 08:12:44AM -0500, forc...@safe-mail.net wrote: I have in my torrc file this line: Okay. Thanks to help from lark on IRC, I think we've chased this one down. It should be fixed in r18575 in trunk. If anybody else can build from source and try it out, that'd be great. (The problem was that we had an internal data structure to represent the union of ExcludeNodes and ExcludeExitNodes, but we weren't ever updating it with country info from the geoip file.) yrs, -- Nick
Reminder: Please use the friendly bugtracker.
Hi, all! This is a reminder to everybody who's been sending bug reports to the or-talk mailing list. There is a bug tracker for Tor at https://bugs.torproject.org/ . The purpose of the bugtracker is to collect all the information about each bug in one place, to help diagnose it, and to make sure that we don't lose track of any bugs. Please, unless there is some reason you can't, report bugs there. Why? Because the alternative kinda sucks. If a bug _isn't_ on the bug tracker, then there is more risk that we'll lose track of who is working on which bug; or which bugs are the same as other bugs; or which bug got fixed in which version, or worse: which bugs are fixed and which aren't. (When I run into a bug on or-talk, I try to copy it to a tor-bugs mailbox, but I worry that I miss some, or that other people more suited to fixing particular bugs aren't seeing them.) (Yes, I know that the 'flyspray' tracker is annoying. Some time around when we start 0.2.2.x development, we'll probably be switching to Trac.) Thanks again for everybody's help in making a better Tor! yrs, -- Nick Mathewson
Re: No such file or directory: router-stabilit; unverified-consensus, cached-extrainfo
On Sat, Feb 14, 2009 at 03:33:23AM -0800, Germershausen wrote: I am using the Debian testing package with tor 0.2.0.34-1 and I am getting some error messages in my debug.log. Maybe i can ignore those lines or not? You can ignore those; they're at level info. If they were important they'd be at warn. They're there because Tor is trying to read some files to see whether they're present. -- Nick
Re: Excludenodes not considered?
On Sun, Feb 15, 2009 at 08:12:44AM -0500, forc...@safe-mail.net wrote:
I have in my torrc file this line:
ExcludeNodes {de},xxx,yyy
Despite the German nodes should not be used, some circuits use some of them,
right now for example
LavendarMan (Online)
Location: Worms, DE
IP Address: 89.12.25.230
and
susebib (Online)
Location: DE
IP Address: 90.135.0.47
The first one is in Germany according to a whois, the second one in fact
seems to be in Sweden.
So if the second could be used, why is the first used?
1) Whois is not a good way to find out where a computer actually is.
Whois tells you about where the DNS name is registered, not where the
computer is physically located. GeoIP is a better bet.
(FWIW, both of those addresses seem to be in Germany according to
GeoIP too. But I just wanted to mention that whois is a poor
choice here.)
2) What version of Tor are you running? You didn't say.
3) Tor needs a geoip file to have country detection work. Yours was
installed, right?
4) For some features, like hidden services, Tor needs to use
particular nodes, since those were chosen by the service provider
as introduction points, or they wound up as HS directories. Do you
know if you were you contacting or publishing a hidden service at
the time?
5) Do you know what position in your circuit these nodes occupied?
6) Did you get an INFO log by any chance? (Please don't post it to
the list if it's huge.)
hope this helps,
--
Nick
Re: Grrr...SafeLogging doesn't work in 0.2.1.12-alpha :-{
On Tue, Feb 10, 2009 at 02:59:44PM -0500, Roger Dingledine wrote: [..] All of that said, at some point we should teach clients to discard v3 certs from authorities they don't recognize. Otherwise they'll just sit around in the cached-certs file taking up space. I'll put that on the todo list. No need; I've just done the fix in svn r18480. -- Nick
Re: Some Bones to Pick with Tor Admins
On Tue, Feb 10, 2009 at 06:24:27PM -0500, Ted Smith wrote: On Tue, 2009-02-10 at 18:17 -0500, Ringo Kamens wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It absolutely would. Here are some things TorButton defends against that wouldn't be covered in your scenario: 1. Unauthenticated Updates 2. CSS Tracking (I think it does anyways) 3. Flash and auto-opening of files 4. Browser referral and user-agent tracking Ringo To be fair, though, 1, 3, and 4 could be configured away in default FireFox. Updates can be disabled, flash can be removed, files can be set to ask, referrals can be disabled, and UA can be modified in firefox or in Privoxy. As Martin notes, privoxy won't modify your SSL connections for you. Torbutton protects against many other attacks that regular Firefox configuration can't protect you against, too. See the Torbutton design document at https://www.torproject.org/torbutton/design/ for a more full list. -- Nick
Tor on win98 [was Re: Some Bones to Pick with Tor Admins]
On Tue, Feb 10, 2009 at 04:51:42PM -0700, mark485ander...@eml.cc wrote: Maybe not many users because Tor's last two versions are buggy and don't allow them to use it? Still plenty of 98se users out there and I have 3 browsers now that can use tor safely. course they will not work on .33 and .34 because tor developers do not adequately test or code their program. This is a simple matter, no great task. Maybe they are just lazy? Dear Mark, I remember back in 2005 when Tor broke on windows 95 for you. Back then, you didn't call us names. Instead, you told us what errors you were getting, which versions worked for you and which didn't, and helped debug the problem. That worked out great, IMO. Here's the thread: http://archives.seul.org/or/talk/Aug-2005/msg00099.html As Roger noted, we are perfectly glad to keep Tor working on older and stranger platforms than yours. Heck, we've taken patches to get Tor working on IRIX and AIX. And you don't need to be able to write code to contribute! If a win98 user with decent debugging skills (you?) would like to help us figure out what exactly broke Tor on win98, I would be glad to try to help figure out what's needed to fix it. To be clear, you're saying that 0.2.0.32 worked, but 0.2.0.33 didn't? And you're saying that there is no useful error message, just a crash with a GPF message? One very interesting part of your first message was when you said, not within vidalia. (If anybody else has a copy of win98 they can fire up, and they want to help track this down, then the more the merrier. Alternatively, it might be useful for somebody who knows windows history to look through the code that changed between the affected versions, or to look at any changes in the build methodology between the affected versions, or such.) BTW: Please knock it off with the insults. They don't make me develop any better or faster, and they don't make the list a better place. yrs, -- Nick
Re: another BADEXIT found $8424E8653469B1EFF87E79E8599933A3BAF8FDB2
On Mon, Feb 09, 2009 at 11:10:28PM -0600, Scott Bennett wrote: [...] I think it would be a useful modification for the authorities to be able to flag IP addresses and address ranges with BadExit in addition to being able to flag nicknames and key fingerprints. That way, when a case like apple arises, its career could be greatly hindered by flagging the /24's of their ISPs. Internally, this ability exists. In the relevant configuration file, authority operators can mark entire IP ranges as BadExit. This doesn't get propagated to the consensus; instead, they automatically vote for any OR that shows up in a marked IP range as being BadExit. The result's the same, but the client code and the consensus format get to stay a little simpler. yrs, -- Nick
Re: Lame and unimportant
On Fri, Jan 23, 2009 at 04:39:42PM -0500, Justin Coffi wrote: Line 834 in log.c has a typo. I caught it in .2.1.9-alpha and told myself that if I saw it in the next upgrade I'd say something. I just spotted it in 0.2.1.11-alpha. log_warn(LD_CONFIG, No such loggging domain as %s, domain); Patched, thanks! (Apparently I can't detect triple-letters. I stared at your message for about 60 seconds trying to figure out what the problem was.) peace, -- Nick
Re: command line control software
On Tue, Jan 20, 2009 at 11:18:33PM +0300, ivvmm wrote: Hello, Is there any command line control software? Excuse me for that question. Just read control-spec.txt and found it very easy to talk to Tor server via telnet. But it would be rather convenient to use some tuned tool. Check out contrib/tor-ctrl.sh in the Tor source distribution. It may need some hacking to do what you want, but it should be a good start. If you come up with any improvements, feel free to send us patches. yrs, -- Nick
Re: cannot compile 0.2.1.10-alpha
On Thu, Jan 15, 2009 at 11:33:28AM +0800, zmj wrote: Nick and coderman, thank you for your responding. I downloaded the 0.2.1.10-alpha source tarball again and configure it and make it. It succeeded this time. It's running normally as a client now. And then I come back to the first tarball I've downloaded a few days ago, re- configure it and make it again, also succeed this time. I just don't know how could this happen. Strange! If the failure ever happens again, please save the config.log so we can get a better idea what's going on. I'm afraid I don't know what's up with your other issue. Could it be some kind of resource exhaustion thing? I didn't think that XP Server had that kind of problem. The diagnostic and workaround approaches people discussed at bug 98 may be apropos. (That reminds me: I must get back to libevent hacking!) yrs, -- Nick Mathewson
Re: tor over ipv6
On Mon, Jan 19, 2009 at 07:54:53PM +0100, Udo van den Heuvel wrote: Just a thought: With the previous tor experiences in mind w.r.t. services blocking me, I thought about IPv6. I could run a somewhat open relay on an IPv6 number via a IPv6 in IPV4 tunnel if I (ever) get that to work. My isp (xs4all) offers such a tunnel for free and a (small?) IPv6 subnet to go. a) does tor work well with IPv6? No. Right now, it doesn't work at all with IPv6. There are two kinds of ways Tor might support IPv6: first, .. Hang on! This is a FAQ! The state of, and issues surrounding, IPv6 in Tor are explained here: https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#IPv6 peace, -- Nick
Re: cannot compile 0.2.1.10-alpha
On Tue, Jan 13, 2009 at 08:38:34PM -0800, coderman wrote: On Tue, Jan 13, 2009 at 7:59 PM, zmj zan...@gmail.com wrote: windows xp+sp3+mingw ... how did you invoke configure? what version of mingw? It would also be helpful to have a copy of the config.log script that configure generated, since something seems to have gone wrong there. The file torint.h is only supposed to define ssize_t if the platform has no ssize_t, but it seems that yours has one in sys/types.h that autoconf did not detect. (The config.log file will be very big. Please do not email it to the whole list. Just compress it and send a copy to me and coderman, if you could.) thanks, -- Nick Mathewson ni...@freehaven.net
Re: tor controlport wants authentication even if authentication is switched off
On Wed, Jan 07, 2009 at 11:59:41PM +0100, Sebastian Schmidt wrote: Thanks for your reply now I understand :) ! But this isn't explained in control-spec.txt. Good point. I've cleaned it up a bit. Thanks! yrs, -- Nick
Re: tor controlport wants authentication even if authentication is switched off
On Wed, Jan 07, 2009 at 07:03:03PM +0100, Sebastian Schmidt wrote: [...] Why does TC tell me authentication is required even if it's switched off? Or is this the default reply if a not supported command was given to it? Even if authentication is turned off, the first command on the control connection needs to be AUTHENTICATE (or PROTOCOLINFO). This is a fix for a neat cross-protocol attack where the attacker tricks your web browser into talking to the control port and generating a string where most of the lines are ignored, up until the lines the attacker actually generated. From control-spec.txt: Before the client has authenticated, no command other than PROTOCOLINFO, AUTHENTICATE, or QUIT is valid. If the controller sends any other command, or sends a malformed command, or sends an unsuccessful AUTHENTICATE command, or sends PROTOCOLINFO more than once, Tor sends an error reply and closes the connection. -- Nick
Re: SSL certificate checker plugin for Firefox?
On Wed, Dec 31, 2008 at 01:21:53PM +0100, Matej Kovacic wrote: Hi, problaby you have seen that: http://www.phreedom.org/research/rogue-ca/md5-collisions-1.0.ppt My question is - is there a plugin for Firefox, which saves info about certificate of a website. When user comes back next time, plugin should check prevous certificate and the new one. If there is change, it should raise alarm. I haven't evaluated it closely, but the Petname tool for firefox may do some of what you want. -- Nick
Re: Tor on Android
Nice stuff! A few comments. On Sun, Dec 28, 2008 at 03:55:21PM -0800, Adam Langley wrote: [...] 9) Build libevent Download libevent % export CC=agcc % ./configure --host=arm-eabi I had to manually disable select support in config.h and remove select.c (and everything else to do with select) from the Makefile because bionic seems to be missing fd_mask structures. I also didn't bother building anything in /test. Hopefully you end up with libevent.a (probably in .libs). Copy it to mydroid/out/target/product/generic/obj/lib. Hm. Libevent should be made to detect this. Ordinarily, fd_mask is defined in sys/select.h or something it includes. Can you grep around a little in the Android headers to make sure it's not defined anywhere? If it isn't, we can probably define it to long without hurting anything, so long as we define NFDBITS to match. 11) Build tor I used 0.2.0.32 Firstly, Android doesn't include deprecated OpenSSL functions, so add a wrapper to src/common/crypto.c: I've changed trunk to use RSA_generate_key_ex when we have it, and to only use RSA_generate_key on OpenSSL 0.9.7, which doesn't have RSA_generate_key_ex(). This way, we won't need to copy code from OpenSSL and make our license even more complicated. ;) (A reminder to folks: when you paste code that you didn't write, please mention the fact? Thanks!) [...] -#ifndef __LOG_H +#ifndef __TOR_LOG_H I noticed in trunk that the header files didn't use a consistent macro naming scheme, so I've switched them all to use the _TOR_FILENAME_H convention, which seemed least likely to collide with anything. --- tor-0.2.0.32/src/or/buffers.c 2008-11-20 14:14:26.0 -0800 +++ tor-0.2.0.32-agl/src/or/buffers.c 2008-12-28 12:03:08.0 -0800 @@ -14,6 +14,7 @@ * memory, file descriptors, or TLS connections. **/ #define BUFFERS_PRIVATE +#include src/common/log.h #include or.h Hm. Usually if system headers are getting searched before our headers, that's a sign that the C compiler is acting weird. Can you investigate this one a little more? As you can tell, I'd like 0.2.1.x to build out-of-the-box for Android, especially given how little code changing seems to be required. Yrs, -- Nick Mathewson
Re: Tor on Android
On Sun, Dec 28, 2008 at 07:24:17PM -0800, Adam Langley wrote: On Sun, Dec 28, 2008 at 6:30 PM, Nick Mathewson ni...@freehaven.net wrote: Hm. Libevent should be made to detect this. Ordinarily, fd_mask is defined in sys/select.h or something it includes. Can you grep around a little in the Android headers to make sure it's not defined anywhere? If it isn't, we can probably define it to long without hurting anything, so long as we define NFDBITS to match. It's not defined. This is probably a mistake on bionic's part since, from reading around, fd_mask is POSIX. Rather than change libevent, probably bionic should be changed. I'll look at doing that tomorrow. If so, bionic should be changed. But sometimes writing portable software means building on platforms that do silly things. If the broken bionics are widespread, libevent could cope pretty easily, since it only uses fd_mask for sizeof(fd_mask) which it uses to calculate how many bytes to allocate for an fd_set. If the code instead just always allocated a multiple of sizeof(long) bits per fd_set, it would be more concise anyway, and not significantly less correct. Also, android has a config include file which is included in all compiles. This might well be a mistake as it defines HAVE_SYS_SOCKET_H and that's pretty rude. Yeah. If you want to do something like this, the usual trick is to post-process the config.h so that all the macros now start with a common prefix that won't conflict with the regular autoconf macros. For an example, recent libevent versions should do it right; old ones had the same problem as Android. [...] With a little investigate, the issue is in the agcc script. I had it add the libevent directory as an include path, but it put's -I options last on the resulting command line. Thus libevent's log.h was getting picked up. I've attached a version which collects -I arguments and puts them first on the gcc command line It would be neat if you sent the agcc patch upstream. :) [...] and this allows tip-of-SVN to build with these modifications: Interesting! Both were clearly errors in the source. Both patches are now applied. If you're feeling brave, try configuring Tor with the --enable-gcc-warnings option: it will warn about other compilation issues that we might want to care about. -- Nick
Re: Tor on Android
On Sun, Dec 28, 2008 at 08:01:26PM -0800, Adam Langley wrote: On Sun, Dec 28, 2008 at 7:24 PM, Adam Langley a...@imperialviolet.org wrote: from reading around, fd_mask is POSIX. Rather than change libevent, probably bionic should be changed. Nick, does this work for you? http://review.source.android.com/6445 Looks fine by me. -- Nick
Re: [Fwd: (Probably) a known problem?] - cant run a relay node
On Wed, Dec 03, 2008 at 11:52:50AM -0500, pho...@rootme.org wrote: [...] A few things, you probably haven't received a response because no one has a good idea how to fix it. You may have 2 issues, one is that libevent can't find nameservers, and the other is that the config options are broken. As for the dns issues: https://bugs.torproject.org/flyspray/index.php?do=detailsid=813 or https://bugs.torproject.org/flyspray/index.php?do=detailsid=868 These bugs are now fixed in svn trunk, I think. The fixes should be in 0.2.1.9-alpha, assuming that the fix was really a fix. -- Nick
Re: [Fwd: (Probably) a known problem?] - cant run a relay node
On Wed, Dec 03, 2008 at 06:35:19PM +0100, Fabian Keil wrote: [...] While we're talking about DNS issues, I recently got: Nov 30 06:25:02.803 [notice] Tor 0.2.1.6-alpha (r17011) opening new log file. Nov 30 06:25:02.818 [warn] eventdns: Unable to add nameserver 164.148.169.81: error 2 Nov 30 06:25:02.818 [warn] eventdns: Unable to add nameserver 34.148.169.81: error 2 Nov 30 06:25:02.818 [warn] Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf' (6) Nov 30 06:25:02.819 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying. The nameservers were indeed unreachable at that time (the traffic limit was reached and the system offline), but earlier Tor versions continued to run and started working again once the system was back on the net. This was bug 691; it should be fixed in 0.2.1.9-alpha when it comes out. https://bugs.torproject.org/flyspray/index.php?id=691do=details This is probably a good time for me to encourage people to use the bugtracker at bugs.torproject.org to report and track bugs. It lets us do a better job of collecting and consolidating information about each bug, and of making sure that nobody forgets about it until it gets fixed. yrs, -- Nick
Re: Tor cleverness?
On Mon, Nov 17, 2008 at 06:54:49PM +, Geoff Down wrote: Hi, two questions: I renamed (with 'mv') the file I was sending Tor logs to whilst Tor was running. I actually moved it to a different directory. The log data kept being written to that file. How? Welcome to Unix. :) A file on Unix exists independently of its location in the directory hierarchy. This is why you can have multiple hard links on the filesystem all pointing to the same underlying file. Programs that have opened the file keep reading or writing to the same file even if it is moved... or deleted. For more information, look up inodes. If you want to rotate your logs, sent a HUP signal. Tor will treat this as a sign to close and reopen them, thereby creating new files if you have moved the old ones away. Secondly, does sending a USR2 signal to Tor 0.2.0.31 (r16744) switch on debug level logging as stated in the manual? I've tried it and it seems not to work - except I got some debug-level entries after I sent a shutdown signal. It should. Looks like there was a bug; I've checked in a fix. -- Nick
Re: Any plans to fix tor for OpenDNS?
On Thu, Nov 13, 2008 at 11:17:20AM -0500, Praedor Atrebates wrote: I use OpenDNS servers and tor messages always contain a message that my service provider may be hijacking DNS requests. It isn't a problem for functionality of tor but it is somewhat annoying to see that warning all the time. Is there any plan to make tor fully friendly with OpenDNS so these messages can go away? The problem isn't that Tor is unfriendly with OpenDNS. The problem is that OpenDNS is unfriendly to the Internet. Tor is giving you those warnings becaue OpenDNS is intentionally giving false answers to its questions. I've heard that OpenDNS has a tell me about real DNS records, not about your own fantasy version of DNS option somewhere in its configuration settings; if it does, you should probably set it so that Tor is getting the real DNS hierarchy. yrs, -- Nick
Re: Problems runing Tor on Vista x64
On Mon, Nov 10, 2008 at 11:51:45PM -0500, [EMAIL PROTECTED] wrote: On Mon, Nov 10, 2008 at 09:51:00AM +0100, [EMAIL PROTECTED] wrote 0.7K bytes in 16 lines about: : Nov 10 09:34:42.445 [err] Error from libevent: evsignal_init: : socketpair: No error It reads like libevent doesn't like something in the wow32 subsystem inside 64-bit vista. Do you get a drwatson crash dump? There are two errors here: - The above error message is totally useless. Future versions of libevent should give a better error for this case. - The error above usually happens when your firewall or antivirus software is blocking connections to 127.0.0.1 (that is, it's blocking connections from your computer to your computer). This is pretty broken. First, check if your firewall software is up to date. (This is windows, so you might need to randomly reboot.) Second, check whether you can tell it to allow Tor to connect to localhost. -- Nick
Re: SANS Paper: Detecting Tor
On Sun, Nov 09, 2008 at 09:54:53PM -0500, Roc Admin wrote: I just read this article in the SANS reading room called Detecting and Preventing Anonymous Proxy Usage http://www.sans.org/reading_room/whitepapers/detection/32943.php Cosmetic issues: 1) It's Tor, not TOR. 2) The paper cites the website rather than any of the actual published academic papers on Tor: lame. 3) The paper doen't say when the research was done or what version of Tor was used, so it may not be _inaccurate_ so much as outdated. Actual issues: The Tor-detection method described in this paper involves looking for a string in the outgoing connections. You wouldn't know it from reading the paper, but the string in question is part of the CNAME field of a certificate sent from a client to a server. We don't follow that protocol any more; in particular see proposal 124 and proposal 130. Where Tor stands today: We're a lot better at avoiding dumb regex-matching attacks in the Tor protocol than we were before. When an 0.2.0.x client is talking to an 0.2.0.x server, there should not be any regular expressions that can be used to distinguish the data stream from a regular HTTPS session. (Some may remain; we may have missed some details. Nonetheless, the approach described in this paper doesn't work on any recent version of the Tor protocol.) -- Nick
Re: any middlemen seeing DoS currently?
On Fri, Nov 07, 2008 at 01:38:28PM +0100, Eugen Leitl wrote: I've seen continuous table state increase since about 3.5 hours. It went up from 1 k baseline to 5 k. Anyone else seeing this? Any alternative explanation to DoS? (ISP throttling?). Judging by the timing, I'd think it might be related to a bug we only uncovered on Friday. Why Friday? That was the first time that a directory authority's certificate expired before it could be replaced. The bug was that clients repeatedly asked directory caches for a new certificate over and over, without noticing that they were getting something expired and deciding to wait for a while. That bug should be fixed in newer versions of Tor. Also, all the authority operators should (if we can make them) get way more careful about checking certificate expiry times. -- Nick
Re: php hex code for cookie authentication to controller?
On Tue, Oct 21, 2008 at 11:52:33AM -0700, Wesley Kenzie wrote:
per 5.1 Authentication in control-spec.txt: To authenticate, the controller
must send the contents of this file, encoded in hexadecimal.
Fine, but when using the following in PHP:
$ch = fopen('cookiefilename', 'r');
$auth_value = fread($ch, 128);
$send_auth_value = AUTHENTICATE \. bin2hex($auth_value) . \\r\n;
$fh = fsockopen('127.0.0.1', controlportnumber);
fwrite($fh, $send_auth_value);
$buf = fgets($fh);
... I get 515 Authentication failed: Wrong length on authentication cookie.
What's the actual length of $auth_value? If it's not
AUTHENTICATION_COOKIE_LEN (32, I think), that's when I'd expect that
error.
Also, I don't know PHP so well, but maybe you should specify 'rb'
instead of 'r'.
--
Nick
Re: php hex code for cookie authentication to controller?
On Tue, Oct 21, 2008 at 04:29:08PM -0700, Wesley Kenzie wrote: What's the actual length of $auth_value? If it's not AUTHENTICATION_COOKIE_LEN (32, I think), that's when I'd expect that error. Thanks, Nick. The length of $auth_value is 32 though, and the length of bin2hex($auth_value) is 64. D'oh! I didn't read the code closely enough: Try omitting the quotes. They're only for sending a literal value. -- Nick
Re: Tor 0.2.1.5-alpha is out
On Thu, Sep 11, 2008 at 05:52:21AM +, otto otto wrote: When I try to build Tor 0.2.1.5-alpha on Solaris10 I get the following warning and can't build the binaries.: geoip.c: In function `geoip_get_client_history': geoip.c:446: warning: comparison between signed and unsigned gmake[3]: *** [geoip.o] Error 1 gmake[3]: Leaving directory `/usr/local/lib/tor-0.2.1.5-alpha/src/or' Hm. If it's treating warnings as errors, you'll need to stop passing --enable-gcc-warnings to ./configure for the time being. I think I fixed this warning in r16759; if you can fetch trunk from the Subversion repository, it would be good to know whether the warning is gone for you now.
Re: Google's Chrome Web Browser and Tor
On Thu, Sep 04, 2008 at 03:20:34PM -0700, Kyle Williams wrote: Hi all, I've been playing around with Google's new web browser and Tor. I thought it might be good to share my findings with everyone. After reading Google's privacy policy[1], I for one would not want to use this on a regular basis, if at all. The first bug I tried was an old one I found with Firefox; the NEWS:// URI type. Any link that has a NEWS:// URI will launch Outlook Express and attempt to contact the server in the URL...without using Tor. The second bug I found resulted in local file/folder disclosure. This is very similar to the one I found in Internet Explorer. The third bug I found was with MIME-TYPEs, specifically Windows Media Player supported formats. The BANNER tag can also leak your IP address when the playlist is loaded *IF* WMP is not set to use a proxy. Also, a playlist in WMP can specify protocols that use UDP, hence, no proxy support...no Tor. On the flip-side, it is very cool how each browser tab is it's own process, making several types of attacks much more difficult. However, with an invasive privacy policy, local proxy bypassing, and local files/folders able to be read from your hard drive, I've decided not to use this browser. It just doesn't feel privacy/anonymity friendly to me. Anyone else want to chime in on this? I dig what I've heard of the Chrome architecture, but it seems clear that, like every other consumer browser, it's not suitable for anonymous browsing out-of-the-box. The real question will be how easy it is to adapt it to be safe. Torbutton, for instance, has proven to take some pretty extreme hackery to try to shut down all of Firefox's interesting leaks. If it turned out to be (say) an order of magnitude easier to extend Chrome to be anonymity-friendly, that would be pretty awesome. We'll see, I guess. Has anybody looked into Chrome's extension mechanisms? It would be neat to know how hard it would be to address the information leaks addressed in, say, https://www.torproject.org/torbutton/design/ . yrs, -- Nick
Re: DNS lookup types
On Wed, Aug 20, 2008 at 05:16:39PM -0400, Erilenz wrote: Hi, When using DNSPort or tor-resolve, you can look up A records and PTR records, but not NS or MX records. Can this functionality be added? It can be. Somebody would need to write a proposal (see the process in http://www.torproject.org/svn/trunk/doc/spec/proposals/001-process.txt ) for it and implement it. This would be a good project for somebody who wanted to get familiar with the Tor internals. yrs, -- Nick
Re: MaxOnionsPending questions
On Fri, Aug 15, 2008 at 04:58:48AM -0500, Scott Bennett wrote: The tor man page says, MaxOnionsPending NUM If you have more than this number of onionskins queued for decrypt, reject new ones. (Default: 100) Does onionskins in this context mean cells or cell payloads? Neither. It means incoming CREATE request payloads. (Why onionskin? In the original Onion Routing designs, onions were structures made with multiple nested PK encryption and used to create circuits. In Tor, circuits are built interactively, one hop at a time, in order to get forward secrecy and (trivially) prevent replay attacks. Instead of sending an entire onion, we send one layer of the onion --or onionskin-- at a time.) What is a typical high water mark for the number of onionskins actually in a decryption queue at one time? Under what circumstances? How can one find out what the actual high water mark is for one's own tor server? Is there a way to reset the current high water mark to 0, so that one could find out usage levels on a periodic basis? These are all good questions! Pending onionskin requests are managed in the cpuworker.c file, but I don't think high-water marks are tracked. A patch to handle this better would be welcome. -- Nick
Re: exit node tortila adds material to www.barnesandnoble.com home page
On Thu, Aug 07, 2008 at 03:26:37PM +0200, Steffen Schoenwiese wrote: On Thursday 07 August 2008 12:19:22 Scott Bennett wrote: [...] The point is, this is written in way that hardly anyone, even native germans, would bother to read it, so I'm not 100% convinced someone would deliberately set this up for a broad audience to take notice of this content in that way. Hasn't there been a thread lately about tor mixing up pages or something like that? Maybe that's the case here too. Can you reproduce your findings? Yep. If the exit node doesn't create this failure mode for every attempt to load the page, then this might conceivably be another occurance of the mysterious bug 779: https://bugs.torproject.org/flyspray/index.php?do=detailsid=779 I've got a possible fix checked in to trunk, but nobody has replicated the bug well enough to confirm that the fix makes the bug go away. Nevertheless, since the fix does indeed fix a real problem in the code that is consistent with what we know about bug 779, I think we should backport it anyway. yrs, -- Nick
Re: Tor 0.2.0.30 does not bootstrap when FastFirstHopPK 0 in torrc file
On Sun, Aug 03, 2008 at 09:30:56PM +0200, Erwin Lam wrote: Hello, Today, I upgraded my Tor client to version 0.2.0.30 (an RPM for SUSE 10.3 obtained from the Packman repository). Because I know something changed with respect to the format of the information supplied by the directory servers, I stopped the Tor process, removed all files from /var/lib/tor, and restarted Tor, expecting it to fetch information from the directory servers again. After one hour, there was still no information obtained from the directory servers. There was only a state file in /var/lib/tor. Using Tor was not possible. After playing around with the options in the torrc file, I was able to solve the problem by commenting out the line FastFirstHopPK 0. Apparently, Tor 0.2.0.30 is not able to bootstrap when the line FastFirstHopPK 0 is in the torrc file. I wonder whether this is a bug or intended behaviour. Looks like a bug. I've added it to flyspray as bug 797: https://bugs.torproject.org/flyspray/index.php?do=detailsid=797 yrs, -- Nick
Re: Mixed pages - serious bug of tor
On Thu, Jul 17, 2008 at 02:30:25AM +0200, slush wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 More information: I tried to repeat this bug (really sorry for all relays operators). I found that this part of python code breaks connection of standalone browser. Since this is getting discussed on IRC, and or-talk, and other email, I think we should start collecting all the info we have in one place. This bug is now on the bugtracker as bug 779, at https://bugs.torproject.org/flyspray/index.php?id=779do=details I've got some speculations about possible causes written there, but no hard conclusions yet. This doesn't look like it will be an easy one to track down, but here's some stuff that would help: - Debug-level logs of the error occurring. Obviously, these need to be logs that start _before_ the data gets messed up. - The actual content of a page or file corrupted in this way. Screenshots are not as helpful, since it's not so easy to analyze what the corruption actually _is_ at the byte level once a browser is done rendering it. Without more data, Roger thinks our best bet would be getting a good test network working here so that we can reproduce the bug at an exit node under our control and see what's happening there. I think that our best option (again, assuming that nobody comes through with more data) is to look through the code until we find something that would explain the bug. I have a possible lead, but not a thorough enough etiology to be sure that it's the _right_ lead. yrs, -- Nick
Re: question about cached-status
On Thu, Jul 10, 2008 at 02:59:57PM -0700, Steve Southam wrote: Hi Hi! Since you replied to Roger's 0.2.0.29-rc email, I initially assumed that you were referring to the directory protocol as used in 0.2.0.x. For 0.1.2.x and earlier, the answers are different. But since your subject line says cached-status, and that's a directory used by 0.1.2.x and earlier, I don't know which version of the protocol you mean. I'll try to answer for both. When a network status is downloaded by a client, how does it determine how long the status is usable for? In the v3 protocol, as used by 0.2.0.x, it has an expiry time. From dir-spec.txt: valid-until SP -MM-DD SP HH:MM:SS NL [Exactly once.] The end of the Interval for this vote. After this time, the consensus produced by this vote should not be used. See 1.4 for voting timeline information. In the v2 directory protocol, as used by 0.1.2.x, clients refresh individual status documents on a rolling schedule as described in section 5.1 of dir-spec-v2.txt. (Caches follow the rules in section 4.2.) If the server that the status came from goes offline, how does the client know not to use it? In the v3 directory protocol, the network status document is a multiply signed consensus that you can get from any cache. If an authority signing the consensus goes offline, a working consensus can still be made as long as more than half of the authorities are present. If a cache goes offline, the client can get the consensus from another cache. (The client can tell that the cache is down when it tries to connect there and fails.) In the v2 directory protocol, each authority has its own view of the network, ance clients download a view per authority from a cache. If a cache goes down, clients act as in v3 (they try another cache). If an authority is down for a long time, clients should eventually give up trying to download that status document. hope this helps, -- Nick
Re: Circuit question
On Sat, Jul 05, 2008 at 12:23:18PM +0300, Evgeniy Minakov wrote: Hello, I have a question about the circuit construction. The getinfo circuit-status sometime returns response without any exit nodes. Which node used as exit node in this case? First, you might be wrong about what nodes are exits. The Exit flag in the networkstatus document is not a perfect view of whether a node can be used as an exit: to actually see whether Second, not all circuits are built for delivering traffic to the internet. Some are built for testing tor servers, some are for rendezvous points, and so on. You can see circuits' purposes in events if extended events are enabled.
Re: Circuit question
On Fri, Jul 11, 2008 at 11:37:04AM -0400, Nick Mathewson wrote: [oops. Didn't end the paragraph.] First, you might be wrong about what nodes are exits. The Exit flag in the networkstatus document is not a perfect view of whether a node can be used as an exit: to actually see whether a node can support a connection to a given service, you need to check its exit policy. yrs, -- Nik
Re: Tor 0.2.1.1-alpha is out
On Wed, Jun 18, 2008 at 01:12:45AM -0400, Roger Dingledine wrote: [...] - Never use OpenSSL compression: it wastes RAM and CPU trying to compress cells, which are basically all encrypted, compressed, or both. Is compression negotiation (or lack thereof) visible to sniffers? I'll leave this question for Nick. Good point! I think 0.2.1.1-alpha might take the wrong approach here; If it does, I'll make 0.2.1.2-alpha smarter. (Ah well. That's why it's an alpha.) yrs, -- Nick
Re: controller GETINFO ns/id/fingerprint s record
On Thu, May 29, 2008 at 12:03:48PM -0700, Wesley Kenzie wrote: On Tue, May 27, 2008 at 02:19:22PM -0700, Wesley Kenzie wrote: where does the data originate from when the controller GETINFO command is used? Does it just grab data out of the cached* files on disk? Or poll one of the directory authorities? Or something else? I am still waiting for someone to help with this question. Using a controller interface, when I issue a GETINFO ns/id/* or GETINFO desc/id/* command where does the response data come from? Does it just come out of the cloud from one of the directory authorities? Does it get read from the local cached* file(s)? Does it get calculated dynamically in real time? It gets answered by your local Tor process based on the directory information that it has locally. It doesn't trigger any new fetches. So how often is the local directory information updated? See https://www.torproject.org/svn/trunk/doc/spec/dir-spec.txt , section 4.3 and section 5.1. See also the FetchDirInfoEarly option. And if I use the controller to GETINFO desc/all-recent and GETINFO ns/all and spin through all the responses, is this sufficient to ensure the local directory information is as current as possible? No. GETINFO commands do not influence the download schedule. Yrs, -- Nick
Re: Fwd: Logistics of International Policy Restrictions (project liberation)
On Tue, May 27, 2008 at 03:00:12PM -0400, [EMAIL PROTECTED] wrote: [...] It's also news to me that the US State Dept. funded Tor. Perhaps we should update the sponsors page, https://www.torproject.org/sponsors.html.en. Wilfred might have erroneously thought that IBB is part of the state department. That's a pretty common misconception. yrs, -- Nick
Re: Router Flags
On Fri, May 23, 2008 at 12:47:54AM -0500, Scott Bennett wrote: On Fri, 23 May 2008 00:05:37 -0500 Nathaniel Dube [EMAIL PROTECTED] wrote: Can someone explain what these router flags mean? Some of them I have a good [...] These have been explained in the documentation available at the www.torproject.org web site. Have you read it? If you have read it and still do not understand the explanations, please let us know. Specifically, see sections 3.2 and 3.3 of https://www.torproject.org/svn/trunk/doc/spec/dir-spec.txt
Re: controller GETINFO ns/id/fingerprint s record
On Wed, May 21, 2008 at 09:21:20PM -0400, BarkerJr wrote: What is the criteria for getting listed as an Exit node in the s record for the controller interface's GETINFO /ns/id/fingerprint? You need to have two of these three ports wide open: 80, 443, 6667. No, I don't think it's fair that you have to open unencrypted ports to be given the Exit badge. But, yes, it's just a badge, and people will still use your exit even if you don't have the badge. In particular, it's used to try to predict which nodes will have most of their bandwidth used in being an exit, in order to avoid using up their bandwidth with relay traffic. See path-spec.txt. yrs, -- Nick
Re: a serious TOR adversary?
On Wed, May 21, 2008 at 05:47:41PM -0500, Eugene Y. Vasserman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Thus spake Bernardo Bacic, on 5/21/08 6:45 AM: | This link http://web.crypto.cs.sunysb.edu/spday/ contains a summary | description of a possible TOR threat. | | Does anyone have more details? opinions? | | | (apologies if this has been discussed before, i read the list only as | much as time permits) Although timing-based attacks have been demonstrated against non-timing-preserving anonymity networks, they have depended either on a global passive adversary or on the compromise of a substantial number of Tor nodes. Incorrect: Steven J. Murdoch. Hot or Not: Revealing Hidden Services by their Clock Skew; Nicholas Hopper, Eugene Y. Vasserman, and Eric Chan-Tin. How much anonymity does network latency leak?. (Full disclosure: I'm one of the authors of the second paper). See also Locating Hidden Servers by Lasse O/velier and Paul Syverson, which motivated Tor's guard node design. yrs -- Nick
Re: ContactInfo?
On Sun, May 18, 2008 at 11:41:02PM +0200, Karsten Loesing wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Nathaniel, | In the torrc file is the ContactInfo option. Here's an example. | | #ContactInfo 1234D/ Random Person nobody AT example dot com | | My question is, what format should I put my GPG key? That doesn't matter so much. The intention of the contact line is not to parse it automatically (previous attempts were not very successful), but are read by humans. In fact, it might be better to obfuscate that line a bit in order to prevent the bots from collecting your address -- or make their lives a bit harder. Further, in most cases your GPG key won't be used to encrypt notice message to you or verify your mails to us anyway. Though when we want it, we *really* want it. :) The short-key format is usually good enough, though if you want to include a fingerprint or a long keyid, that would probably be fine. (A line with a long keyid would look like: ContactInfo 1024R/ Somebody nobody at example dot com You can make gpg emit long keyids rather than short ones by specifying --keyid-format long on the command line.) yrs, -- Nick Mathewson
Re: Tor server for port 443
On Mon, May 19, 2008 at 04:31:42AM -0400, Grant Heller wrote: Can I get some feedback regarding the deployment of an exit node restricted to port 443? A port-443-only exit would definitely be useful. The usefulness of an exit is IMO basically what you allow, not what you restrict. -- Nick Mathewson [EMAIL PROTECTED]
Re: unnamed exit nodes
On Wed, May 14, 2008 at 06:15:18AM -0400, [EMAIL PROTECTED] wrote: Hi, Using tor/vidalia, how can I know the ID number of a tor node? I want to put some unnamed in my black list, but as a few nodes have the same name, it looks hard. What happens if I put just unnamed in the blacklist? Will ALL servers with this name banned? I don't know offhand for Vidalia, but for Tor, just refer to nodes by their key fingerprint, sticking a $ before the fingerprint, as in: EntryNodes $70A08C76BCB9ADE55907029B83DB6891957AC92C If you want to force a given name binding, you can use the format $70A08C76BCB9ADE55907029B83DB6891957AC92C=peacetime to only match a Named server with the given nickname and key, or $70A08C76BCB9ADE55907029B83DB6891957AC92C~peacetime to match any server with the given nickname and key. This feature could be better documented, though, and I'd love to get a documentation patch to explain all of this better. :)
Re: Question
On Wed, May 14, 2008 at 01:26:02PM +0200, Ivan ??ipka wrote: Hello everyone :) I'm a computer science student studying Tor (if necessary I can send the same mail from my official college mail). I have questions about Tor and the types of services that use it (in the aspect of the reputation of Tor as a security parameter). I'd like to talk to anyone from the dev team because it's hard to get the accurate info from forums. From the mails I see on this list I suppose I'm posting this question in the wrong place. If that is the case could you please tell me where to / whom to send this question? [EMAIL PROTECTED] should work fine.
Re: Exit node's IP
On Thu, May 15, 2008 at 08:09:49AM +0300, Evgeniy Minakov wrote: Hello all, Is it possible for controller to get current circuit nodes IPs through GETINFO command? You can get current circuits by watching circuit events, or by looking at the results of GETINFO circuit-status. From there, you can get the IP of the last node of a given circuit by looking up that node's server descriptor with GETINFO desc/... , or just looking it up in the latest consensus. If you want to know the exit node for a given stream, also check out streams as they attach to circuits; see control-spec.txt for full details. The getinfo address shows local ip instead of current exit node IP Remember, there's more than one the current exit node IP. Tor can (and often does) have multiple circuits open at once, in use for different purposes and for different time windows. , I think its useless. It's useful for some purposes; just not yours. GETINFO address is good for helping the user figure out what external address Tor has guessed for the server. If you're behind any interesting kind of firewall, determining this is not completely obvious.
Re: About the MapAddress option
On Thu, Mar 20, 2008 at 05:17:18PM -0400, [EMAIL PROTECTED] wrote: Hi, I connect to servers through SSH on port 22 with Tor: The SSH client connects to localhost:9050 and privoxy does the job with Tor. I connect to the server IP, like 1.2.3.4 Is there a way to select an exit node so that all connections to the 1.2.3.4, or even better to 1.2.3.4:22 use this exit node? As the MapAddress for http? Sure. Just do Mapaddress 1.2.3.4 1.2.3.4.servername.exit This will effect all connections to 1.2.3.4, not just those to port 22.
Re: Proposal: Incorporate Unreachable ORs into the Tor Network
On Sat, Mar 22, 2008 at 11:11:12AM +, Robert Hogan wrote: I'm not sure how much merit this proposal has, or how serious it's problems are. Does anyone have any thoughts on it? Are the problems I've outlined fatal, or is there a problem with it I've missed? I suspect one or the other. Hi, Robert! I think this is definitely a step in the right direction, with some tricky issues associated with it. In particular, it represents a big deviation from Tor's current clique topology. We should definitely drop the clique assumption (for scaling reasons if nothing else) at some point, though, and there's no reason it can't be soon. Send it to or-dev and let's talk about it there? yrs, -- Nick
Re: max number of file descriptors hard coded
On Sun, Feb 17, 2008 at 06:36:13PM +0100, Olaf Selke wrote: Narf! debugging the [warn] Error creating network socket: Too many open files messages I just found the max number of file descriptors apparently being hard coded in or.h to a value of 15.000. Raising the number using ulimit -n thus shows no effect. Thanks, Olaf! I've added it to the bugtracker as bug 611: https://bugs.torproject.org/flyspray/index.php?id=611do=details I'll try to get a fix in for the next release. -- Nick
Tor meetup in San Francisco this Thursday, 7pm, Sugarlump Coffee Lounge
On Tue, Jan 22, 2008 at 01:13:24AM -0500, Nick Mathewson wrote: Hi, all! I'll be in San Francisco for most of this week, and I thought it would be neat to have a Tor Folks meetup on Thursday, probably in the late afternoon or early evening. Let me know (off-list) if there's any interest, and I'll figure out where -- probably a coffee shop or something. Hi again! Thanks to local recommendations, we'll be meeting up at the Sugarlump Coffee Lounge at 7pm Thursday night. I'm planning to stick around for a couple hours. According to my source, they're an okay compromise between tolerable coffee and likely to have enough space in case a bunch of people show up. Where: Sugarlump Coffee Lounge, 2862 24th Street at Bryant. When: 7pm. What: No actual agenda; just hanging out, meeting local Tor users, operators, and enthusiasts. Hope you can make it! peace, -- Nick pgpV7JwKPLKYy.pgp Description: PGP signature
Tor meetup in San Francisco this Thursday
Hi, all! I'll be in San Francisco for most of this week, and I thought it would be neat to have a Tor Folks meetup on Thursday, probably in the late afternoon or early evening. Let me know (off-list) if there's any interest, and I'll figure out where -- probably a coffee shop or something. yrs, -- Nick Mathewson pgpIRukqHlGhT.pgp Description: PGP signature
Re: SORBS vs Tor and the world
On Mon, Jan 07, 2008 at 09:33:50AM -0500, Michael Holstein wrote: and no involvement with SORBS idiots is required. If you don't like SORBS, don't use them. TOR doesn't try to be invisible .. if a site admin wants to block anonymous ($whatever) .. they're free to do so, and SORBS just makes it easier (the TOR dnsbl). Statistically speaking, the volume of non-legitimate email coming from anonymous routers makes TOR a pretty easy target. We've been through this before, and so far as I know, the problems with the SORBS Tor DNSBL remain more or less as they were before. (I don't want to single out SORBS here; other dnsbl services for Tor nodes have taken the same approach.) I support everybody's right to reject anonymous email; I support everybody's right to reject email based on any criteria they like. It's your server. But the last time I looked, the SORBS Tor list tried to include _all_ Tor servers, not just the ones that are configured to relay SMTP. In other words, the effect of these lists is not only to block anonymous SMTP via Tor, but also to block email from people who run middleman Tor servers that don't deliver anonymous email at all. That seems pointlessly coarse-grained to me. Now, if somebody wants to block anonymous email, and they don't mind blocking all non-anonymous email from people running Tor servers that don't even support anonymous email, then these dnsbls meets their needs just fine. On the other hand, if your only goal is to block anonymous SMTP, and you agree that blocking all Tor servers is very overreaching, you might instead try looking at the more targetted DNSEL service available at http://exitlist.torproject.org/ It lets you block _exactly_ those servers that relay traffic on given ports to your address. For a more thorough rationale, and a fairly detailed spec of how to make a compatible implementation, see https://www.torproject.org/svn/trunk/doc/contrib/torel-design.txt yrs, -- Nick pgp18F6h2IJeJ.pgp Description: PGP signature
Re: tor26 missing certificate messages today
On Sun, Dec 09, 2007 at 11:42:22PM -0600, Scott Bennett wrote: This afternoon my tor server began logging the following messages: Dec 09 15:10:18.474 [notice] We're missing a certificate from authority tor26 with signing key : launching request. Dec 09 15:11:19.530 [notice] We're missing a certificate from authority tor26 with signing key : launching request. Dec 09 15:12:18.357 [notice] We're missing a certificate from authority tor26 with signing key : launching request. These messages continued at the rate of approximately one per minute until the final one: Dec 09 16:03:08.509 [notice] We're missing a certificate from authority tor26 with signing key : launching request. Does anyone know the reason for these messages? And the reason why they eventually stopped appearing 53 minutes later? I finally tracked these down; for the resolution, see comments on bug 569: http://bugs.noreply.org/flyspray/index.php?id=569do=details Many thanks to everybody who helped! yrs, -- Nick pgp9k3tasur5v.pgp Description: PGP signature
Re: [OT] more from Cryptome on NSA, Windows firewals, mail services
On Wed, Jan 02, 2008 at 02:47:11PM -0600, Eugene Y. Vasserman wrote: Thus spake Ringo Kamens on Sun, 23 Dec 2007: (snip) Also, we know the NSA and DoJ have engaged in this type of activity in the past such as working with Microsoft to secure vista and having their private key inserted into windows versions so they could decrypt things. I've heard of the Vista bit, but what are you referring to, as far as having a decryption key for Windows stuff? I know they had one in... What was it? Lotus Notes? He's probably referring to the NSAKey key in NT 4. For more information, see http://en.wikipedia.org/wiki/Nsakey It's a secondary code-signing key, allegedy to be used if their primary code signing key needed to be revoked. If you believe Microsoft, the key was called _NSAKEY because it was introduced in order to meet NSA requirements for a secondary key. Naming things after the software or organization that requires them, rather than after their actual purpose, is not unusual for Microsoft: Their office XML spec is littered with stuff like the notorious AutoSpaceLikeWord95. Personally, I don't believe that contemporary operating systems are so secure that the NSA would rather have security holes custom-built for it instead of just using the ones that are already there. peace, -- Nick pgpvqf2Q0iQQG.pgp Description: PGP signature
Re: Tsocks and DNS
On Sat, Dec 29, 2007 at 07:54:28PM -0500, Ringo Kamens wrote: I have a question regarding tsocks. According to http://wiki.noreply.org/noreply/TheOnionRouter/TorifyHOWTO#DNSNote, tsocks leaks DNS requests and it suggests I either use tor-resolve or apply the patch at http://www.totalinfosecurity.com/patches/tor.php?. Does the tsocks version in the Ubuntu repositories still have this problem (for instance, when I do an apt-get install tor it automatically installs torify and tsocks)? Would you suggest using the patch? I just read through the patch, but I haven't tried it out yet. If I'm understanding it right, it extends tsocks so that in addition to replacing connect() as usual, it also replaces gethostbyname(), getaddrinfo(), and so on with versions that use Tor's resolve facilities. It doesn't support reverse lookups. There are some weird bits to the code: the authors seem to be unaware of AutomapHostsOnResolve -- or maybe they didn't want to rely on having it turned on. In any case, they duplicate its functionality in something they call a deadpool. They don't say what license their code is distributed under. Honestly, I'd test it out and see whether it works with any given application. For some applications, this approach will work; for some, it won't. You might also want to try recent alpha Tors' DNSPort feature; if you can get an application to use Tor as your resolver, you can be very sure indeed that no data is being leaked. yrs, -- Nick pgpV0jLZ5HxBQ.pgp Description: PGP signature
Re: Tsocks and DNS
On Wed, Jan 02, 2008 at 04:41:32PM -0500, Nick Mathewson wrote: [...] They don't say what license their code is distributed under. I spoke too soon. tsocks is under GPLv2, and they distribute a patched tsocks with the license in place. Honestly, I don't want to make it sound like there's anything wrong with this code; DNS APIs a royal pain in the neck to implement, and DNS logic is a pit of nasty exception cases and things you were assumed to know. -- Nick pgpBs1Lm9NRSB.pgp Description: PGP signature
Re: Your computer is too slow to handle this many creation requests!
On Wed, Dec 26, 2007 at 10:43:32PM +0100, Olaf Selke wrote: morphium wrote: Tor is only using about 80 MBits, so that aren't even 10% of the Bandwith I want to give for tor. eeh? Wanna give Tor 800 MBits/s? Tor is a cpu hog efficiently using one core only. On my Debian box the other three cores together serve with less than 10% load having the NumCpu config file option set to four. As I understood RSA encryption only is done distributed on multiple cores. Yeah, this _is_ a problem. I'd like to get it so that AES is also parallelized (since AES is where a well-behaved Tor spends most of its time), but the changes involved are probably tricky enough that they'll have to wait for the next development series. If anybody would like to mess around with this ahead of time, there's one easy place to mess around, and one hard place to mess around: - The easy place is when cells are encrypted on circuits. For a middleman node, this represents one AES operation out of 3. Right now, it happens in relay.c. - The hard place is getting all openssl crypto to get parallelized. yrs, -- Nick pgpnJzrZyQBgc.pgp Description: PGP signature
Re: Build Problems on Solaris
On Wed, Dec 05, 2007 at 08:27:39PM +, Steve Murphy wrote: Hi Nick. Got a bit further building from svn-12686. Throws up a warning about tor_threads_init Also tried --disable-threads did the same. Ah, I think I see what this is. In 0.2.0.x, threads are now mandatory. But threads default to off on solaris for some old reason. (I believe we fixed the bug in question.) Try configuring with an explicit --enable-threads? I'll change the behavior assuming this works. (Also, make sure you have libevent 1.3e or later; earlier ones had Solaris bugs, I believe.) yrs, -- Nick pgpxY7KEY2ypN.pgp Description: PGP signature
Re: suspicious log warning messages
On Thu, Nov 08, 2007 at 07:02:53AM -0600, Scott Bennett wrote: Last night my tor server logged some unexpected messages. I've waited about twelve hours to see whether any relevant discussion appeared on this list. Thus far, it hasn't, so I'm posting them here in hopes that someone will explain what he/she was doing. [...] Nov 07 19:37:24.205 [warn] Not enough good signatures on networkstatus consensus Nov 07 19:37:24.221 [warn] Unable to load consensus directory dowloaded from server '128.31.0.34:9001' No more messages of this sort have appeared since the last one shown above. There's a new v3 directory authority, ides, run by Mike Perry. Apparently, adding it caused some weird bug to show up in the new certificate download code. See Flyspray bug 546. yrs, -- Nick Mathewson pgpjWKaK2FnEe.pgp Description: PGP signature
Re: peculiar 0.2.0.9-alpha behavior this a.m.
On Wed, Oct 31, 2007 at 12:24:11PM -0500, Scott Bennett wrote: [WARNING: I've included a *lot* of log entries in this note, interspersed with my observations and comments, so it is quite long and finding my remarks will require careful scanning.] Among the various windows I keep open in X, I usually have one open for /var/log/messages and another for /var/log/tor/notices.log (using tail -f to display them). Early this a.m. I was startled to see suddenly appear the following after /var/log/tor/notices.log had been silent for about twelve hours: Oct 31 02:51:21.091 [notice] Our directory information is no longer up-to-date enough to build circuits. Oct 31 03:03:40.827 [notice] I learned some more directory information, but not enough to build a circuit. [...] And all has been well since the restart. I am mystified as to what went wrong that tor found itself unable to build circuits, even though I could see that it was adding new data to cached-descriptors.new quite frequently. Did anything strange happen to the directory authorities early this a.m. that might have induced this behavior? Hi, Scott! I'd suspect a bug in 0.2.0.9 alpha; I'm not aware of any authority bug. Unfortunately, the log messages still leave me clueless as to what's going on. If this happens again, can you: A) Make a copy of cached-descriptors* and cached-consensus, so that the state can be reproduced to try to investigate what's up. B) If possible, log at info for a while: it says a lot more about what's happening with downloads. I'm going to try to make those Not enough info messages more useful in the next alpha; sorry I can't figure this out just now. yrs, -- Nick Mathewson pgpbodUz50Poz.pgp Description: PGP signature
