Delivery-Date: Thu, 11 Dec 2014 10:01:09 -0500
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.7 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,
	DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID,
	URIBL_BLOCKED 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 ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id BB40F1E04D1;
	Thu, 11 Dec 2014 10:01:07 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id ED0742DCF5;
	Thu, 11 Dec 2014 15:01:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 6DE4B29172
 for <tor-talk@lists.torproject.org>; Thu, 11 Dec 2014 15:00:59 +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 2PAdDIlFrKI5 for <tor-talk@lists.torproject.org>;
 Thu, 11 Dec 2014 15:00:59 +0000 (UTC)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com
 [IPv6:2607:f8b0:4001:c05::236])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 4282F284B2
 for <tor-talk@lists.torproject.org>; Thu, 11 Dec 2014 15:00:59 +0000 (UTC)
Received: by mail-ig0-f182.google.com with SMTP id hn15so4973594igb.3
 for <tor-talk@lists.torproject.org>; Thu, 11 Dec 2014 07:00:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:sender:from:date:message-id:subject:to:content-type;
 bh=9wp60tW/AkIcGj0qa0u7GipBgmlNKZFrB44SLqjVKrU=;
 b=c2triFXDCxDUAhjqS90pzM/r7ZUtZiXv1CTDZk+qntOuGSk9U/M8mWRZ9iILvnQn7Q
 5PXV7ybIdW1/WR+Y7AhMlh6z4/XFTA9jxbmJbjVzv3i3h9n91vL2Gp49Eat9FMZLLYd2
 /ib6XWqpecG+Ogu7i2h/0J/j+x1K1Af28NOCO1QoIIl83iBEcAKey7ZCaX1NY9bz0a7O
 w4He3vDjEB1lauuE+X0kzFQNpLzyrVY//xSLTk8IM8WnxYJVdCSxaPIhtUU7y2EcGeqS
 IyvLcgBaPFDqpn95ZWaprCpXSDxF18XU30URZOsrgILm6HQkCIxwrVXnU2tncwOrIhGE
 V5tg==
X-Received: by 10.42.25.12 with SMTP id y12mr11518790icb.74.1418310049770;
 Thu, 11 Dec 2014 07:00:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.167.6 with HTTP; Thu, 11 Dec 2014 07:00:09 -0800 (PST)
From: usprey <usprey@gmail.com>
Date: Thu, 11 Dec 2014 16:00:09 +0100
X-Google-Sender-Auth: 5ESCTChT92Gub3aDxi_o7Sk48Qc
Message-ID: <CAOmikWEJLxx649fdCmvPmJSPJTMdTKc1jME7BhbwPGBqbQj66w@mail.gmail.com>
To: tor-talk@lists.torproject.org
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: [tor-talk] Idea: Public verification of exit nodes and their
 maintainers - Fwd: [tor-relays] specifying your own entrance and 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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

Please see forwarded messages from tor-relays below.

Summary:
The problem: A user suspects interference with traffic on exit connections.

Users ad-hoc solution: The user has defined his own (too short?) list of
trusted exits.

Proposed long-term solution: Use existing web of trust systems to let exit
node maintainers sign their exit nodes fingerprint to obtain a
"Trusted"-flag. Maybe also let users sign relays fingerprint to obtain
higher trust score.

Discussion:
The objective of the proposed solution is to compile an as comprehensive as
possible, publicly available, list of trusted exit nodes.
Exit node maintainers should already be aware of the implications of
running an exit node and have taken the advised precautions. A signed
object including the exit nodes fingerprint could also include a statement
of compliance with exit node guidelines.
As my own exit nodes IP address is already traceable to my person, I would
have no problem signing off on the integrity of my exit node, and in my
case also my ISPs.

---------- Forwarded message ----------
From: usprey <usprey@gmail.com>
Date: 11 December 2014 at 04:08
Subject: Re: [tor-relays] specifying your own entrance and exit nodes
To: tor-relays@lists.torproject.org


Inline below.

On 11 December 2014 at 01:46, tor-exit0 <tor-exit0@intersafeit.com> wrote:

> On 12/10/2014 4:52 PM, usprey wrote:
>
> > I do not have a full understanding of how the DirAuth works, but how
> > about an out of band verification process, to ensure the
> > trustworthiness, for exit nodes specifically. This would minimize the
> > hazzle for people who wishes to use trusted exit nodes, and maximize the
> > number of explicitly trusted exit nodes.
>
> How would the trust be quantified by such a verification process?


You could use existing web of trust systems to let maintainers sign the
relays fingerprint.
In addition to this users could also sign the fingerprint and the exit
would first be flagged trusted when a critical mass of users have signed.
I'm aware this breaks anonymity, but would be a way to flag an exit as
trusted.


> For
> example, how would this prevent the operator of a good exit from
> changing their mind about tampering with traffic or the cooperation of
> one or more exit owners in monitoring or sharing traffic information for
> correlation?


It won't, but the maintainer would be putting her name and reputation on
the line, in the web of trust fingerprint scenario above. Code words for
trust is openness and accountability.
I'm not aware how one acquires a bad exit flag, but it should be possible
to automate tests verifying non-interference with exit connections.


> I'd also be curious how such a system would stand up in the
> event that control over a validated exit is compromised without the
> owner realizing it.


I suspect that most people contributing +100Mbps bandwidth, are in some way
IT professionals and know what they are doing and have followed the general
guidelines for physical, network and software security.
A signing process for a maintainer could also include a statement of
compliance with specific guidelines.


> It seems to me that most validation techniques offer
> a trade off between accountability and anonymity which may also pose a
> concern for some people.
>

Definitely, why it shouldn't be mandatory, but a way to flag trusted and
accountable exits.


>
>
>
> _______________________________________________
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>

---------- Forwarded message ----------
From: usprey <usprey@gmail.com>
Date: 11 December 2014 at 00:52
Subject: Re: [tor-relays] specifying your own entrance and exit nodes
To: tor-relays@lists.torproject.org


I run an exit node,
https://atlas.torproject.org/#details/F14B7BF44F9B170DFF628F237E0C7E8D631F957E,
and I'm also quite new on the list and learn new things about Tor everyday,
so please bear with me.

I do not have a full understanding of how the DirAuth works, but how about
an out of band verification process, to ensure the trustworthiness, for
exit nodes specifically. This would minimize the hazzle for people who
wishes to use trusted exit nodes, and maximize the number of explicitly
trusted exit nodes. Since relay maintainers are already publicly listed and
traceable I would not have any problem signing off on my own, and a few
other maintainers I know personally, exit nodes.

As per
https://compass.torproject.org/#?exit_filter=all_relays&links&sort=cw&sort_reverse&country=&exits_only&top=10
the
exit probability of the Top 10 exit relays with the highest consensus
weight is 12,2046%, and per
https://compass.torproject.org/#?exit_filter=fast_exits_only&links&sort=cw&sort_reverse&country=&exits_only&top=10
the
exit probability of the Top 10 fast exit relays is 11,2452%, so you
wouldn't need many maintainers joining a signing/verification scheme to
account for a lot of the bandwidth on the network.

On 10 December 2014 at 21:58, Seth <list@sysfu.com> wrote:

> Assuming there are certain Tor notes being run by parties hostile to my
> own interests, what are
> the pros and cons of specifying one's own list of trusted entrance and
> exit nodes?
>
> I run a Tor relay at home 24/7 and use that as my entrance point. I do
> this to provide cover traffic for my own Tor use as well as help out the
> network.
>
> I also try to use Tor for all my daily web browsing when possible. This
> has given be a lot of headaches.
>
> Besides the demoralizing barrage of Cloudfare captchas, I've had a lot of
> problems with dropped connections, timeouts, SSL cert warnings, fatal
> errors connecting to HTTPS sites. I started to get a gut feeling, warranted
> or not, that some exits nodes might be meddling with my traffic.
>
> To combat this I changed the configuration on my local Tor relay to use
> only exit nodes run by organizations or people that I felt I could trust. I
> didn't bother with specifying entrance nodes because I could not see what
> the gain would be.
>
> This seems to have curbed some of the problems, with the tradeoff that
> responsiveness is much more inconsistent.
>
> I'm just curious if restricting exit nodes to a few dozen that you trust
> effectively defeats most of the purpose of using Tor. What would be the
> bare minimum of Tor exit nodes a person would need to use in order to make
> life difficult for the Panopticon surveillor scum?
>
> If this post is more appropriate for Tor-talk, please let me know
> _______________________________________________
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
-- 
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

