Delivery-Date: Mon, 09 May 2016 10:58:41 -0400
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	T_RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 35B651E02B6;
	Mon,  9 May 2016 10:58:39 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 0DC3A3A413;
	Mon,  9 May 2016 14:58:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 2B3B23A40B
 for <tor-talk@lists.torproject.org>; Mon,  9 May 2016 14:58:31 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id rDA0jP8fMQAC for <tor-talk@lists.torproject.org>;
 Mon,  9 May 2016 14:58:31 +0000 (UTC)
Received: from meiko.romanrm.net (meiko.romanrm.net
 [IPv6:2001:bc8:3829:100::1])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id 0093D39F6D
 for <tor-talk@lists.torproject.org>; Mon,  9 May 2016 14:58:30 +0000 (UTC)
X-Greylist: delayed 564 seconds by postgrey-1.34 at eugeni;
 Mon, 09 May 2016 14:58:30 UTC
Received: from natsu (unknown [IPv6:fd39::e9:9eff:fe8f:1bcf])
 by meiko.romanrm.net (Postfix) with SMTP id 21207145FE1;
 Mon,  9 May 2016 14:49:01 +0000 (UTC)
Date: Mon, 9 May 2016 19:48:57 +0500
From: Roman Mamedov <rm@romanrm.net>
To: Andreas Krey <a.krey@gmx.de>
Message-ID: <20160509194857.04b157cc@natsu>
In-Reply-To: <20160509142833.GA29776@inner.h.apk.li>
References: <20160509142833.GA29776@inner.h.apk.li>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Cc: tor-talk@lists.torproject.org
Subject: Re: [tor-talk] Are squid proxies acceptable on exit nodes?
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1144378261257364697=="
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

--===============1144378261257364697==
Content-Type: multipart/signed; micalg=pgp-sha1;
 boundary="Sig_/2PboZxYgDWCuYi.M4/x72gN"; protocol="application/pgp-signature"

--Sig_/2PboZxYgDWCuYi.M4/x72gN
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Mon, 9 May 2016 16:28:33 +0200
Andreas Krey <a.krey@gmx.de> wrote:

> To me it looks like the tor exit is using a squid
> proxy - is that an acceptable thing to do as a
> relay operator?

Squid itself is just a tool, sure it can cache, it can log all requests, bu=
t is
it configured to do so? Not necessarily so.

On the other hand it has very advanced filtering capabilities and ACLs by
hostname/URL/destination IP/etc (including regexp support), and maybe that's
why it's being used -- to block some of the simplest cases of malicious
behavior?

You could ask whether or not applying any filtering strips the exit node
operator from their "common carrier" status (if there was any in the first
place), but that's another question, and one that should be more troubling =
for
the exit node operator, not for its users.

As it stands, I'd say the mere presence of Squid does not equate "evil", it
all depends on how it's set up and what it's being used for.

--=20
With respect,
Roman

--Sig_/2PboZxYgDWCuYi.M4/x72gN
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlcwo1wACgkQTLKSvz+PZwgCkgCfaA2jjtu9jWhat5NEy9c/DOFa
h+sAoIxZvh8qXlpvQL8dhwVYQhRebJAr
=Ezcc
-----END PGP SIGNATURE-----

--Sig_/2PboZxYgDWCuYi.M4/x72gN--

--===============1144378261257364697==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

--===============1144378261257364697==--

