EFF Promotes Freenet-like System Tor

An anonymous reader writes "The Electronic Frontier Foundation (EFF) just announced that it has become a financial sponsor of Tor, an open-source project to help people 'engage in anonymous communication online.' It sounds like a simpler version of Freenet, e.g. 'a network-within-a-network that protects communication from ... traffic analysis.' Like Freenet, the source-code is freely available and binaries exist for Windows, Linux, etc." Read on for more details.

The submitter continues "It also allows you to install Tor-aware apps, such as an HTTP proxy (for private browsing), or maybe private P2P? Unlike Freenet, it doesn't use massive encryption (as far as I can tell) and relies more on something called onion routing to randomly bounce requests between other Tor proxies, thus obfuscating the IP of the original client. So it allows you to browse regular Internet sites! Maybe it should be considered more of an 'open-source' Anonymizer? But I don't know if it's actually Open Source - you can download the source (and compile it yourself) but I don't know if the developers are letting anyone else touch their code. They are, however, looking for contributors and other forms of help. And, finally, they're hoping people will start running Tor servers!" It's open source, however contributions are handled.

Comments

Re:If they really want

[Anonymous Coward]

It's more than that; the entry nodes don't have to
be trusted. Your communications with them are
encrypted and they know only the next hop in the
circuit -- they do not know the exit node and they
do not know the content of your communication.

Whups, so much for that idea.

[Tackhead]

From the design documents:

Based in part on our restrictive default exit policy (we reject SMTP requests) and our low profile, we have had no abuse issues since the network was deployed in October 2003. Our slow growth rate gives us time to add features, resolve bugs, and get a feel for what users actually want from an anonymity system. Even though having more users would bolster our anonymity sets, we are not eager to attract the Kazaa or warez communities-we feel that we must build a reputation for privacy, human rights, research, and other socially laudable activities.

Well, so much for that. *badaboom*

Re:Solutions are simple.

[pclminion]

IANAL either. This doesn't work.

The DMCA prohibits circumventing a protection on a copyrighted work. Encryption only qualifies as a "protection device" if the person doing the encryption is the holder of the copyright. You can't "protect" what you do not own.

I don't know if the DMCA contains precisely this language, but it's certainly the way it would be interpretted in court.

I'm more interested in the case of using encryption to protect a computer virus. Since the author of the virus actually is the owner of the copyright on the viral code, then the encryption should qualify as a copyright protection device under the DMCA. Law enforcement officials who decrypt the virus to reverse engineer it would be in violation of the DMCA.

Re:If they really want

[weaselp]

The first node knows your IP and the second node, but not the plain text. The last node knows the second-to-last node,the service you are connecting to, and the plain text unless you do some encryption on the application layer (like https).

It's not entirely unlike Mixmaster, only low latency.

Misconceptions about Tor (from Chris @ EFF)

[innerFire]

Hi there! I'm Chris Palmer from EFF. I am working with the Tor developers, so I know a bit about it. I'll try to clear up some questions and misconceptions people seem to have.

1. Spam? Well, spammers already have much better tools than Tor. Namely, botnets. The Tor network currently doesn't support the kind of bandwidth usage spammers can chew up. By their willingness to break the law, spammers and criminals already have good tools to hide their network origin. Tor doesn't really help them. Plus, the default Tor exit policy is to block port 25.

2. Free/open source? Yes, three-clause BSD. EFF would not financially support a non-free/open source project!

3. Do you have to trust the nodes? You have to trust the entry node and the exit node. The entry node can be on your own computer, which I highly advise people to do. It's easy to install on all platforms, so that shouldn't be a hurdle. As far as trusting the exit node: Yes, the exit node can see the plaintext of your communications. That is why you should always use end-to-end encryption, anyway! Remember, all normal Internet routers in your route can read your traffic; Tor is actually BETTER because traffic is strongly encrypted (AES, multiple times) while inside the Tor network.

So, you actually have to trust Tor a bit less than regular Internet routes.

Use encryption. :)

4. Is it like Freenet/Crowds/Anonymizer? Yes, and no. It is like somewhat like those systems in goals, but the design is different. For example, unlike Freenet, Tor helps you talk to the real Internet. Unlike Anonymizer, Tor uses a whole network of proxies, not a single proxy; and the proxies are generic SOCKS proxies, not specifically HTTP.

5. Version number is too low. Is this alpha software? Roger and Nick are very modest. :) Tor works. It is stable, many bugs have been fixed, and the protocol is moderately stable. Tor does not crash randomly or eat all your memory. What's in flux is bigger picture items, such as "How can we reduce our dependency on the central directory server" and "Wouldn't a GUI configuration tool be nifty?"

6. Is there a backdoor? Well, you tell me. The source code is open. Is there a backdoor in other free software you like?

7. Minimum bandwidth requirement? For exit and middleman nodes, yes, you should have a reasonable pipe and a stable machine. "Reasonable" pipe can mean a good DSL connection. Crappy nodes can degrade the network for those poor saps whose circuit goes through one. That is why the directory server operators won't list your server unless it meets basic stability and bandwidth requirements.

Re:Spammers

[miope]

Look the documentation

2. Decide what exit policy you want. By default your server allows access to many popular services, but we restrict some (such as port 25) due to abuse potential. You might want an exit policy that is either less restrictive or more restrictive; edit your torrc appropriately. If you choose a particularly open exit policy, you might want to make sure your upstream or ISP is ok with that choice.

the faq responds your second question

6.1. Can exit nodes eavesdrop on communications? Isn't that bad? Yes, the guy running the exit node can read the bytes that come out there. Our first answer is "then use end-to-end encryption such as SSL", which is great but not always practical. (The corollary to this answer is that if you are worried about somebody intercepting your traffic and you're *not* using end-to-end encryption at the application layer, then something has already gone wrong and you shouldn't be thinking that Tor is the problem.) Our second answer is that in a future release, we plan to have Tor clients recognize when the destination is co-located with a Tor server, and exit from that Tor server. So for example, people using Tor to get to the EFF website would automatically exit from the EFF Tor server (assuming it's nearby in network geography), thus getting *better* encryption and authentication properties than just browsing there the normal way. But this has a variety of technical problems we need to overcome first (the main one being "how does the Tor client learn which servers are associated with which websites in a decentralized yet non-gamable way?"). Stay tuned.