Re: [tor-talk] Idea: Public verification of exit nodes and their maintainers - Fwd: [tor-relays] specifying your own entrance and exit nodes

[Gareth Owen <gareth.owen@xxxxxxxxxx>]

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@xxxxxxxxx> 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@xxxxxxxxx>
> Date: 11 December 2014 at 04:08
> Subject: Re: [tor-relays] specifying your own entrance and exit nodes
> To: tor-relays@xxxxxxxxxxxxxxxxxxxx
>
>
> Inline below.
>
> On 11 December 2014 at 01:46, tor-exit0 <tor-exit0@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> >
> >
>
> ---------- Forwarded message ----------
> From: usprey <usprey@xxxxxxxxx>
> Date: 11 December 2014 at 00:52
> Subject: Re: [tor-relays] specifying your own entrance and exit nodes
> To: tor-relays@xxxxxxxxxxxxxxxxxxxx
>
>
> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> >
> --
> tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk