Delivery-Date: Mon, 16 Jun 2014 16:41: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.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
	autolearn=unavailable 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 moria.seul.org (Postfix) with ESMTPS id A870A1E0D51
	for <archiver@seul.org>; Mon, 16 Jun 2014 16:41:40 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 2FCC8300DD;
	Mon, 16 Jun 2014 20:41:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id D76C43009C;
 Mon, 16 Jun 2014 20:29:30 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at eugeni.torproject.org
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 pyB6P-dAUdem; Mon, 16 Jun 2014 20:29:30 +0000 (UTC)
Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com
 [IPv6:2607:f8b0:400c:c01::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 AFFAB3009A;
 Mon, 16 Jun 2014 20:29:30 +0000 (UTC)
Received: by mail-ve0-f182.google.com with SMTP id oy12so4829117veb.27
 for <multiple recipients>; Mon, 16 Jun 2014 13:29:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :cc:content-type;
 bh=Iiy7DvRc2aeuWINXXGfQIE5XNKNc2vCDD2Iun5y0f+k=;
 b=Xy0tFy2PW2oF1f1ZPvujYcAu+ks0LEqxB1WvrFLHJy6N2ZPxzbn9++J8MO+Pa7ar8J
 FQfc/Jy1VInnMaeI/mv9O6xJ1jTqAnyYwB2iOa907Eu+UrC/1dWWM2GxuGrEeIhXj6Z+
 0OfdYknQJ/cRWJFQRGMkqG6+MvNnSRKnDxByzdRwRGBttdI2peUyUPGqjgxQHPBqyPYj
 EPoj91+Cj/DjGaTcb7lky01H1pT8md/ZU3W1c2EspYVt8wMBy8aXWKOaUZ+3BfFcGnzy
 HoJJk0qrQ3Dec1u3l1xLDNTjBGPfQyiUpghO5xFj+n7JZiW6H7rvtFroaF3sajbYfR7O
 tCJQ==
MIME-Version: 1.0
X-Received: by 10.52.185.72 with SMTP id fa8mr15087272vdc.12.1402950568244;
 Mon, 16 Jun 2014 13:29:28 -0700 (PDT)
Received: by 10.221.65.198 with HTTP; Mon, 16 Jun 2014 13:29:28 -0700 (PDT)
In-Reply-To: <1402937995.95763.YahooMailNeo@web121203.mail.ne1.yahoo.com>
References: <CAD2Ti28NaBtU4b8mMVLVcYvBMACyLwt1tEvOj8F9Z3rgEJcm8g@mail.gmail.com>
 <20140514004021.GK10586@hexapodia.org>
 <CAD2Ti28Ekcqoh_Dw42Vci4Qdgk6hX-PMtVnYYj6or6szern-NQ@mail.gmail.com>
 <537342B8.5040501@massar.ch>
 <CAD2Ti2_7+WZ89J3yG=3z+jh=F3xFaM6cnaJP7KSVAH+aEYEHhQ@mail.gmail.com>
 <5374C2E8.6090703@massar.ch>
 <CAD2Ti28AZgzDPz2Zn=ajc0oVqD1yLr5yw86fgJO_iiZK66kZ7A@mail.gmail.com>
 <1402937995.95763.YahooMailNeo@web121203.mail.ne1.yahoo.com>
Date: Mon, 16 Jun 2014 16:29:28 -0400
Message-ID: <CAD2Ti28cG03QfynENejO-SSaOUbnyKw3O6Zhj2S1bE6xnztdHg@mail.gmail.com>
From: grarpamp <grarpamp@gmail.com>
To: tor-relays@lists.torproject.org
Cc: tor-talk@lists.torproject.org
Subject: Re: [tor-talk] [tor-relays] Ops request: Deploy OpenVPN terminators
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>

On Mon, Jun 16, 2014 at 12:59 PM, Bogglesnatch Candycrush
<bogglesnatch@yahoo.com> wrote:
> On Monday, June 16, 2014 2:29 AM, grarpamp <grarpamp@gmail.com> wrote:
>
>> No, it does not break any anonymity. And it doesn't matter what
>> OpvenVPN sends because it all happens over the users already secured
>> Tor circuit '--'. You just don't understand the model. Here it is
>> again. '<>' is a single computer, there are two computers pictured.
>> Packets travel through the listed processes and computers from left
>> to right. '++' is the usual clearnet beyond the exit box.
>
>> A)
>> <user - ovpncli - torcli> -- <tor_exit_relay_or_ip - ovpn_term_ip> ++
>> world
>
> It seems to me in this case the OpenVPN endpoint would know who the user is,
> based on their OpenVPN client certificate or shared secret.  Even absent
> those, they might be able to do packet fingerprinting, since the packets
> won't be scrubbed.

'know who the user is' ... you need to precisely define that.

know their location [real ip]? - No, Tor protects them from that.
know it's the same recurring OVPN nym? - Not if OVPN is setup to
use ephemeral keying or a single shared secret posted on the wiki.
know their name? - Any exit can sniff users at the tor daemon, OVPN or not.
know their traffic? - Any exit can sniff users at the tor daemon, OVPN or not.
scrubbing? - There is some visibility to the 'raw' tunneled packets from the
user's stack. Similar to OnionCat, or to how browsers 'Panopticlick'...
we should document that so that users can make their own choices,
we provide an openvpn config file, etc.

Ultimately, this essentially brings what would otherwise be
third party OpenVPN service to pair with Tor via the exit relay
operators model everyone is familiar with today. Other than that
 it is an external bolt-on after Tor, and it is improper to compare
it with the expectations/capabilities of Tor as if it were Tor... they
are two completely separate things. It is optional for operators
to run one. And optional for users to use one.

Another aspect... the consensus is scraped and imported into
blocklists because Tor makes no restrictions on such use.
And they are unlikely to do so because TPO wants to play nice.
Now since maybe only a third of these independantly operated OVPN
IP's might be published on the wiki (the die roll thing), the other two
thirds must be found by scanning and then used to see if the shared
access token works. This OVPN service could be ToS'd as being only
for Tor users and not blacklists. Thus any appearance of an unpublished
OVPN IP on a BL could be challenged as to its listing source...
one such successful case of illlegal access to computer against
ToS would send a strong message to BL's not to do that.
A rather thin defensive tactic, but it is worth noting how the
consensus and OVPN differ in this regard.
-- 
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

