Re: chaining JAP and Tor

[Paul Syverson <syverson@xxxxxxxxxxxxxxxx>]

On Thu, Jul 21, 2005 at 03:25:13PM +0000, Ben Clifford wrote:
> Chaining JAP and Tor
> 
> Here I outline a methodology for doing this and I would be very interested 
> to hear back as to what people think of its validity. It requires you to 
> have both JAP and Tor installed on your system. The JAP client is set up as 
> to use the mix cascade system (ie. it is set as an HTTP proxy in your 
> browser and NOT a Socks proxy).
> 

I don't intend to comment about the architecture (other than to say
that it seems probably OK at the level you described it) but rather
to ask what the larger goal is here.

First an aside: I want to respond to a JAP FUD comment that has
already been posted. I do not think that JAP is backdoored right
now. If it were backdoored though (as in the past) I doubt they could
tell us legally. Same is true of Tor by the way, which is why
independent inspection of the source and alertness to sudden
disappearance of the source is recommended. But, even with source code
signed and in hand, you have no direct evidence that the Tor server or
JAP server through which you route is running it; although you can
compile the client yourself. And the source code for JAP is
available. You just have to go to the JAP site to see. It beats idle
speculation.

Back to the main question: what's the point?

We don't have to argue about who has the better/more-realistic/...
system or threat model. You can just take the two threat models
as givens.

Tor's security derives from the adversary not knowing the endpoints of
communication. But if you feed a Tor circuit into a JAP cascade,
anyone can know where it's coming out. Thus, someone who wants to see
where you are connecting can just watch the end of the JAP cascade and
confirm the responder to which you are connecting.

JAP's security derives from persistent clients with similar traffic
profiles (e.g., via padding, although I don't know if that is deployed
currently). Having a bunch of Tor circuits that open and close at
varying times for relatively short intervals with varied
traffic profiles will not satisfy these assumptions and, it should
be relatively easy to bridge the cascade for exiting traffic based
on Tor circuits. So you derive no benefit from sticking a JAP cascade
at the end of your Tor circuit, or put the other way round: you would
ruin the protection of using JAP.

Now, you suggested putting the JAP client before the Tor circuit which
then leads into the cascade. This could govern the sorts of things I
raised in the last paragraph. The problem is that Tor is not designed
to work with this level of traffic padding and regularization. Whether
or not it is practically feasible (of which I am dubious), it seems
likely that it would chase away many of the volunteers that run our
servers.

Also, I don't think it would have reasonable payoff even if feasible.
That's partly because of my views in an ongoing debate between the
free-route and cascade advocates. Fortunately, we can note the
incompatibility of the current systems with their current threat
models without getting into who is right in that debate.

aloha,
Paul