Message-ID: <200308210505.19667.thomas.greene@theregister.co.uk>
Date: Thu, 21 Aug 2003 05:05:19 -0700
From: "Thomas C. Greene " <thomas.greene@...register.co.uk>
To: Florian Weimer <fw@...eb.enyo.de>, bugtraq@...urityfocus.com,
	full-disclosure@...ts.netsys.com
Subject: Re: Popular Net anonymity service back-doored


I agree that the dirty work has to be done on the proxy, but it's reasonable 
to imagine that the client update was issued to maintain compatibility with 
whatever was done to the proxy software. Maybe the two are unrelated as the 
group says, but how can I trust them when they continue to soft-pedal the 
security implications of the back door?

Yes, the code sort of shouts at you, and this may well be a deliberate heads 
up.  However, the group is still in denial, insisting that their service is 
secure (see the press release linked in the Register story). It's not secure, 
and claiming that it is taints anything else they may be doing on behalf of 
users. They're *still* saying it's impossible for anyone to intercept users' 
traffic or identify them. That simply isn't true.  

It's likely were legally prevented from issuing a clear warning, which is why 
I say they should have taken the service down in protest.  I don't know 
German law, but I'd be surprised if the courts can force you to provide a 
communications service just so the Feds can use it.  

Leaving a hint in the source and waiting for someone to call them on it may be 
a legal strategem, but it's not a good way of maintaining user trust.  It 
took too long for this to become public.  A better way to maintain trust 
would be to stage a protest shutdown, or, if that's legally risky, a silent 
shutdown and a subsequent leak to the press.  No decent reporter would reveal 
their source in a case like this, and approaching a journo based in another 
country would add another layer of protection. 

chrz,
t.

On Thursday 21 August 2003 11:38, Florian Weimer wrote:
> "Thomas C. Greene " <thomas.greene@...register.co.uk> writes:
> > traffic might be going straight to Big Brother, right? Wrong. After
> > taking the service down for a few days with the explanation that the
> > interruption was "due to a hardware failure", the operators then required
> > users to install an "upgraded version" (ie. a back-doored version) of the
> > app to continue using the service.
>
> This is technically incorrect.  As far as I know, the client update is
> completely unrelated.
>
> The logging functionality has been implemented in the mixes
> themselves, otherwise you would be able to circumvent it by using a
> different client.  The CVS commit occured on 2003-06-27.  Logging is
> implemented this way: if the last mix in the cascade (which sees the
> request in the clear) detects a suspicious request, it is logged
> together with an ID.  The ID is transmitted (through the cascade) to
> the first mix, which logs the ID and the IP address.  Combining the
> two log files, it is possible to collapse the cascade and backtrack
> the requests.  This exploits that TU Dresden operates both the first
> and last mix in the Dresden--Dresden cascade (which is the only that
> works reliably, AFAIK).
>
> An employee of TU Dresden described this scheme in an interview with
> Heise Online, a German online news site, back in October 2001.  He
> announced an implementation within the next six months, but I don't
> know at the moment if he was speaking for the JAP project as a whole,
> or if he was just expressing his own ideas.
>
> According to the news sources I have read, the court requested
> surveillance based on the target IP address.  However, the source code
> does not contain code to monitor specific (target) IP addresses, but
> an elaborate URL screening facility, based on regular expressions.
> Just by specifying ".*", it should be possible to log all requests
> (and the corresponding IP addresses).  I don't know why the source
> code doesn't implement the surveillance based on IP addresses, as the
> court allegedly requested.
>
> > "What was the alternative? Shutting down the service? The security
> > apparatchiks would have appreciated that - anonymity in the Internet
> > and especially AN.ON are a thorn in their side anyway."
>
> Note that this kind of target-based monitoring would be much harder on
> the plain Internet unless the remote site is willing to cooperate.  A
> broken anonymizer makes this type of surveillance quite easy.
>
> > But that's not the point. Disclosure is the point. The JAP Web site still
> > claims that anonymity is sacrosanct: "No one, not anyone from outside,
> > not any of the other users, not even the provider of the intermediary
> > service can determine which connection belongs to which user."
>
> The official declaration ("Selbstverpflichtung") of the mixes, which
> promises that neither logging will be enabled nor backdoors will be
> implemented, hasn't been updated either.
>
> However, perhaps the JAP team at TU Dresden hadn't much choice.  I
> haven't seen the court order, but I could imagine that they weren't
> allowed to inform the users because it would have harmed the criminal
> investigation.  Following the order while fighting it within the legal
> system is perhaps a wiser choice than just resisting it (and thus
> breaking the law yourself).  But I agree that it takes them awfully
> long to update their web site, now that some information is public.
>
> Finally, they could have avoided all the hassle if they hadn't
> published the source code.  Why did they publish?  I don't believe
> it's an accident.
>
> For BUGTRAQ readers: Symantec strips message headers.  The original
> To: and Cc: are:
>
> To: bugtraq@...urityfocus.com, full-disclosure@...ts.netsys.com
> Cc: "Thomas C. Greene " <thomas.greene@...register.co.uk>

Powered by blists - more mailing lists