Tor question. And remember, I'm not a datacom guy, so NK-me if I ask a stupid question. I recently read that a simple LINUX OS has been written in java. How hard would it be (and would it be meaningful) to write (or modify) a Tor client that could sit on top of a Java LINUX? This could allow anyone at a public computer to open a Java-based Tor client (from a Tor website, of course), from pretty much anywhere (though I imagine Tor-on-Java would be resource hungry). I imagine there are still security concerns, given that the Tor node is not actually "seeing" the machine directly. Thoughts? -TD

From: Eugen Leitl <eugen@leitl.org> To: cypherpunks@jfet.org Subject: [arma@mit.edu: Tor 0.1.1.10-alpha is out] Date: Sun, 11 Dec 2005 09:53:31 +0100

----- Forwarded message from Roger Dingledine <arma@mit.edu> -----

From: Roger Dingledine <arma@mit.edu> Date: Sun, 11 Dec 2005 02:29:03 -0500 To: or-talk@freehaven.net Subject: Tor 0.1.1.10-alpha is out User-Agent: Mutt/1.5.9i Reply-To: or-talk@freehaven.net

This is the tenth development snapshot for the 0.1.1.x series. We fix more crash bugs, fix some anonymity-related problems, and provide major performance speedups and use less memory than the previous alphas.

http://tor.eff.org/download.html

Changes in version 0.1.1.10-alpha - 2005-12-11 o Correctness bugfixes on 0.1.0.x: - On Windows, build with a libevent patch from "I-M Weasel" to avoid corrupting the heap, losing FDs, or crashing when we need to resize the fd_sets. (This affects the Win32 binaries, not Tor's sources.) - Stop doing the complex voodoo overkill checking for insecure Diffie-Hellman keys. Just check if it's in [2,p-2] and be happy. - When we were closing connections, there was a rare case that stomped on memory, triggering seg faults and asserts. - We were neglecting to unlink marked circuits from soon-to-close OR connections, which caused some rare scribbling on freed memory. - When we're deciding whether a stream has enough circuits around that can handle it, count the freshly dirty ones and not the ones that are so dirty they won't be able to handle it. - Recover better from TCP connections to Tor servers that are broken but don't tell you (it happens!); and rotate TLS connections once a week. - When we're expiring old circuits, we had a logic error that caused us to close new rendezvous circuits rather than old ones. - Fix a scary-looking but apparently harmless bug where circuits would sometimes start out in state CIRCUIT_STATE_OR_WAIT at servers, and never switch to state CIRCUIT_STATE_OPEN. - When building with -static or on Solaris, we sometimes needed to build with -ldl. - Give a useful message when people run Tor as the wrong user, rather than telling them to start chowning random directories. - We were failing to inform the controller about new .onion streams.

o Security bugfixes on 0.1.0.x: - Refuse server descriptors if the fingerprint line doesn't match the included identity key. Tor doesn't care, but other apps (and humans) might actually be trusting the fingerprint line. - We used to kill the circuit when we receive a relay command we don't recognize. Now we just drop it. - Start obeying our firewall options more rigorously: . If we can't get to a dirserver directly, try going via Tor. . Don't ever try to connect (as a client) to a place our firewall options forbid. . If we specify a proxy and also firewall options, obey the firewall options even when we're using the proxy: some proxies can only proxy to certain destinations. - Fix a bug found by Lasse Overlier: when we were making internal circuits (intended to be cannibalized later for rendezvous and introduction circuits), we were picking them so that they had useful exit nodes. There was no need for this, and it actually aids some statistical attacks. - Start treating internal circuits and exit circuits separately. It's important to keep them separate because internal circuits have their last hops picked like middle hops, rather than like exit hops. So exiting on them will break the user's expectations.

o Bugfixes on 0.1.1.x: - Take out the mis-feature where we tried to detect IP address flapping for people with DynDNS, and chose not to upload a new server descriptor sometimes. - Try to be compatible with OpenSSL 0.9.6 again. - Log fix: when the controller is logging about .onion addresses, sometimes it didn't include the ".onion" part of the address. - Don't try to modify options->DirServers internally -- if the user didn't specify any, just add the default ones directly to the trusted dirserver list. This fixes a bug where people running controllers would use SETCONF on some totally unrelated config option, and Tor would start yelling at them about changing their DirServer lines. - Let the controller's redirectstream command specify a port, in case the controller wants to change that too. - When we requested a pile of server descriptors, we sometimes accidentally launched a duplicate request for the first one. - Bugfix for trackhostexits: write down the fingerprint of the chosen exit, not its nickname, because the chosen exit might not be verified. - When parsing foo.exit, if foo is unknown, and we are leaving circuits unattached, set the chosen_exit field and leave the address empty. This matters because controllers got confused otherwise. - Directory authorities no longer try to download server descriptors that they know they will reject.

o Features and updates: - Replace balanced trees with hash tables: this should make stuff significantly faster. - Resume using the AES counter-mode implementation that we ship, rather than OpenSSL's. Ours is significantly faster. - Many other CPU and memory improvements. - Add a new config option FastFirstHopPK (on by default) so clients do a trivial crypto handshake for their first hop, since TLS has already taken care of confidentiality and authentication. - Add a new config option TestSocks so people can see if their applications are using socks4, socks4a, socks5-with-ip, or socks5-with-hostname. This way they don't have to keep mucking with tcpdump and wondering if something got cached somewhere. - Warn when listening on a public address for socks. I suspect a lot of people are setting themselves up as open socks proxies, and they have no idea that jerks on the Internet are using them, since they simply proxy the traffic into the Tor network. - Add "private:*" as an alias in configuration for policies. Now you can simplify your exit policy rather than needing to list every single internal or nonroutable network space. - Add a new controller event type that allows controllers to get all server descriptors that were uploaded to a router in its role as authoritative dirserver. - Start shipping socks-extensions.txt, tor-doc-unix.html, tor-doc-server.html, and stylesheet.css in the tarball. - Stop shipping tor-doc.html in the tarball.

----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

[demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

On Mon, Dec 12, 2005 at 12:12:23PM -0500, Riad S. Wahby wrote:

Tyler Durden <camera_lumina@hotmail.com> wrote:

...

I recently read that a simple LINUX OS has been written in java.

Have a reference handy? I'm just curious to see where they're going with this.

I presume everybody has seen http://www.masswerk.at/jsuix/ right?

I suppose all you'd really need is a linux kernel that'll run on the JVM, which shouldn't be too hard to do.

-- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

Well, I've been playing with one of those little Tor USB doohickeys. But that's a very different thing from allowing anyone, anywhere to pull a Tor client down onto a java virtual machine. Of course I'll grant that such a publically available Tor node offers a kind of anonymity that most Cypherpunks would pass on, but I still maintain that huge increases in quasi-anonymous traffic* is good for those of us who roll our own, more secure communications. -TD * By Quasi-anonymous I mean potentially breakable, but only through the exertion of significant TLA resources. In other words, too expensive to do fishing expeditions on big-mouths.

From: Eugen Leitl <eugen@leitl.org> To: Tyler Durden <camera_lumina@hotmail.com>, cypherpunks@jfet.org Subject: Re: Tor client over Java LINUX Date: Mon, 12 Dec 2005 18:33:18 +0100

On Mon, Dec 12, 2005 at 11:41:25AM -0500, Tyler Durden wrote:

...

This could allow anyone at a public computer to open a Java-based Tor client (from a Tor website, of course), from pretty much anywhere (though I imagine Tor-on-Java would be resource hungry).

There's a Tor park Tor/Firefox appliance, which can be started off local drive or an USB stick.

IIRC the author of Torpark might be developing a Tor Firefox plugin.

-- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

[demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

On Mon, 2005-12-12 at 11:41 -0500, Tyler Durden wrote:

I recently read that a simple LINUX OS has been written in java.

What exactly do you mean by a "simple LINUX OS"? Do you mean a port of all or part of GNU to Java? Part of the Linux kernel? Both? The answers to the rest of the questions vary quite a bit depending on what exactly you meant. This is part of the reason *why* referring to both the kernel and OS as just "Linux" is bad. -- Shawn K. Quinn <skquinn@speakeasy.net>

Tyler Durden <camera_lumina@hotmail.com> wrote:

On the other hand, it occurs to me one does not necessarily need Linux on top of Java at all.

Yup. No reason to increase the complexity any more than necessary to get the job done---you're only adding holes to poke. -- Riad S. Wahby rsw@jfet.org

On Dec 13, 2005, at 5:20 PM, Eugen Leitl wrote:

On Tue, Dec 13, 2005 at 11:16:04AM -0500, Tyler Durden wrote:

...

Of course I'll grant that such a publically available Tor node offers a kind of anonymity that most Cypherpunks would pass on, but I still maintain that huge increases in quasi-anonymous traffic* is good for those of us who roll our own, more secure communications.

A really good multiplier would be to package Tor into a malware vector.

Yeah. That would really work. We should pitch that idea to some spammers :) Enough cover traffic in *THAT* mix-network as well... Cheers, Ralf