Delivery-Date: Thu, 11 Dec 2014 10:33:18 -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_SIGNED,
	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 6B0181E04D1;
	Thu, 11 Dec 2014 10:33:16 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 66D442FFD5;
	Thu, 11 Dec 2014 15:33:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 668342DCA8
 for <tor-talk@lists.torproject.org>; Thu, 11 Dec 2014 15:33:07 +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 1Uk-S169klBN for <tor-talk@lists.torproject.org>;
 Thu, 11 Dec 2014 15:33:07 +0000 (UTC)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com
 [IPv6:2607:f8b0:4001:c03::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 356FC284A7
 for <tor-talk@lists.torproject.org>; Thu, 11 Dec 2014 15:33:07 +0000 (UTC)
Received: by mail-ie0-f182.google.com with SMTP id x19so4985910ier.27
 for <tor-talk@lists.torproject.org>; Thu, 11 Dec 2014 07:33:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=port.ac.uk; s=google-20130730;
 h=mime-version:in-reply-to:references:from:date:message-id:subject:to
 :content-type; bh=FC5ETO2IoNbPibrB/8dLxEqAzEa1uDI1qrM3Uo3aWYk=;
 b=roR0IylayuMEIf6AIwEv2DqFkLwhh3eFe3Qz249ICrIK8giUvKNGtifcx5kTDLEgfY
 GutZ7HEt3HHZqKCAia8vNBVZrq/BHc3v2o2+q268PJkPs8GPJcCLuxn+awmNGaXiC9Pp
 YAVfiD5k9jQ0D7Gx8O8Cs6//rN5JFJIyQR49k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:in-reply-to:references:from:date
 :message-id:subject:to:content-type;
 bh=FC5ETO2IoNbPibrB/8dLxEqAzEa1uDI1qrM3Uo3aWYk=;
 b=fjm/cEyDNei2F8EeJ/u75qtpZJ9zLckwgbNv2CI9kvD/QNMWA9zK+AmCrP0xR0M73e
 8ahafacsaoheg7VDQ31gLZ9HZVdJFSgtmer5mJ7MGEmVoMKXG9nl/v802CMQBAGPtxAP
 d5TCiB3//Ko56I52tUG04rQdUG9G6W4ZsLfVaFoPutJ9DEwqYR518eE9ZnHGJJskJDAX
 5ZAuHszszw0dL4hn1zOm07T9uVYwTnsbjJ+HbAF/NPXO8KlgsvG6O7TMWAZVvsb1Q3Un
 AEQ4ItLlg9V8Ct7zeEDeHOmRXGpCnzVe8YSoJ2bQ7mvzUUSzmJdQm2EplJFsgvW7Ina2
 n3rQ==
X-Gm-Message-State: ALoCoQmV3KjTJ9tRZsv7BDeQUZ5QHPOdopg/6Ck5YgjtqHDfOr5m9qNN+ml3MVg5MfsdIqyMelJ2
X-Received: by 10.42.25.12 with SMTP id y12mr11677892icb.74.1418311984880;
 Thu, 11 Dec 2014 07:33:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.173.134 with HTTP; Thu, 11 Dec 2014 07:32:44 -0800 (PST)
In-Reply-To: <CAOmikWEJLxx649fdCmvPmJSPJTMdTKc1jME7BhbwPGBqbQj66w@mail.gmail.com>
References: <CAOmikWEJLxx649fdCmvPmJSPJTMdTKc1jME7BhbwPGBqbQj66w@mail.gmail.com>
From: Gareth Owen <gareth.owen@port.ac.uk>
Date: Thu, 11 Dec 2014 15:32:44 +0000
Message-ID: <CAOXPy3yHNj=ay4vE=mHEG81=R7YAYby-LLN88-zwjU1Aonuprg@mail.gmail.com>
To: tor-talk@lists.torproject.org
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [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>

Hi

I'm not sure the "web of trust" idea is reliable -  It doesn't seem to work
very well for PGP to be honest.

The second point is that identifiable exit node owners doesn't necessarily
add any security - identities are easily faked including building up
relationships as that identitiy over time.

Limiting the number of nodes you exit through is probably a bad idea too
particularly if an attacker can identify the set.

Best
Gareth





On 11 December 2014 at 15:00, usprey <usprey@gmail.com> wrote:

> 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
>



-- 
Dr Gareth Owen
Senior Lecturer
Forensic Computing Course Leader
School of Computing, University of Portsmouth

*Office:* BK1.25
*Tel:* +44 (0)2392 84 (6423)
*Web*: ghowen.me
-- 
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

