Re: [tor-relays] Ops request: Deploy OpenVPN terminators

[grarpamp <grarpamp@xxxxxxxxx>]

On Mon, Jun 16, 2014 at 12:59 PM, Bogglesnatch Candycrush
<bogglesnatch@xxxxxxxxx> wrote:
> On Monday, June 16, 2014 2:29 AM, grarpamp <grarpamp@xxxxxxxxx> 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-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays