lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ptiyg8jt.fsf@deneb.enyo.de>
Date: Thu, 21 Aug 2003 20:38:46 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: bugtraq@...urityfocus.com, full-disclosure@...ts.netsys.com
Cc: "Thomas C. Greene " <thomas.greene@...register.co.uk>
Subject: Re: Popular Net anonymity service back-doored


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"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>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.2-cvs (GNU/Linux)

iQEVAwUBP0URumOpx4pWo0FrAQLTXQf/aJLMGYtvLpzbB8BtYNFqdoHEQlu/QUmv
gzouWH76cIL6zVJLK7eAM6nNI29itfOm/mJRfAJvU5B7FVAbFfPyhwEuBr4bUCYj
wkIwdM0tQihu+SBdIEIKdrSlfpNbstGJiKkQkPPpa2EREqqVYLadGk95KughJ1AG
f9HJzUG5jbPS/FEXrEYSqudJeVQPVPGUdmXbl0ayq8y2+AtZnk9NCJIFbXlBXf9P
/zK+AoORdDl6t8fzKfUwi/qTu4qads/+eHklAbaKo2EyghjquKubTQdWpQodpt17
2CB/D25ULum2e8LWN6el2AW+PjkyaxeVBenKQV8Rw9Zv2JLenZsWrQ==
=sN0C
-----END PGP SIGNATURE-----


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ