Delivery-Date: Thu, 29 Jan 2015 17:59:04 -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 481591E0A1C
	for <archiver@seul.org>; Thu, 29 Jan 2015 17:59:03 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 1273F2F7F0;
	Thu, 29 Jan 2015 22:58:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id ACA082EF0E
 for <tor-talk@lists.torproject.org>; Thu, 29 Jan 2015 22:58:55 +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 d7n88tNcGdWk for <tor-talk@lists.torproject.org>;
 Thu, 29 Jan 2015 22:58:55 +0000 (UTC)
Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com
 [IPv6:2607:f8b0:400e:c03::22a])
 (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 76AF12E59E
 for <tor-talk@lists.torproject.org>; Thu, 29 Jan 2015 22:58:55 +0000 (UTC)
Received: by mail-pa0-f42.google.com with SMTP id bj1so44301995pad.1
 for <tor-talk@lists.torproject.org>; Thu, 29 Jan 2015 14:58:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=googlemail.com; s=20120113;
 h=sender:message-id:date:from:user-agent:mime-version:to:subject
 :references:in-reply-to:content-type:content-transfer-encoding;
 bh=szHC9P1AvejVDNJMAEkhjYQDltPcNVYivsG0Z9LEWbY=;
 b=BIasKtQoi6LiL3JC1p/UhUTMYO/3jsDROAVFjNLbQ/cdLzXk0FIQ2swvm4V4aqmGx6
 ohmjg2KFn9YuzjTv3eWqCsCMnnNvv/SCaLnIMPpk+uAQ7GMZ2oc6xs+21BETPSaziaeL
 tR9M6YDLpkeHGcPje3Bw7NORwajZbq7OhcbQUXijBqYlFu6WA4Y4zrUDgZg5XZW4rBpv
 lv35F2/fOvE9Rnk2itnkaAp9DhbiObUqRP0bLw7XmG8n46su+hgPP+Jow9+Jr6jzZ2fy
 X2vo43yq+mIjQUoBrn0QIwYGRru2BzXMvopFzLh/JZHouDlf9eGgjkzaatBK7b0x1Nj7
 yhSw==
X-Received: by 10.68.189.167 with SMTP id gj7mr4447207pbc.58.1422572332849;
 Thu, 29 Jan 2015 14:58:52 -0800 (PST)
Received: from krys-red.trunet.local (93.160.173.203.static.cust.vf.net.nz.
 [203.173.160.93])
 by mx.google.com with ESMTPSA id xw1sm8889388pac.47.2015.01.29.14.58.50
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Thu, 29 Jan 2015 14:58:52 -0800 (PST)
Message-ID: <54CABB28.3040105@gna.org>
Date: Fri, 30 Jan 2015 11:58:48 +1300
From: Christian Gagneraud <chgans@gna.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: tor-talk@lists.torproject.org
References: <CAMCPh3yW-1mqmTsiA0vW9ipBpuovWZ06EraNo-bDodSV1=hdbQ@mail.gmail.com>
 <20150129212015.GJ6456@patternsinthevoid.net> <54CAB5E7.8020501@gmail.com>
In-Reply-To: <54CAB5E7.8020501@gmail.com>
Subject: Re: [tor-talk] WebRTC to uncover local IP
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-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

On 30/01/15 11:36, Aymeric Vitte wrote:
>
> Le 29/01/2015 22:20, isis a =E9crit :
>> Even better than disabling it, the Tor Browser Team really needs help
>> from
>> someone with a really strong knowledge of WebRTC and its potential
>> privacy
>> caveats to help us assess which parts of WebRTC (if any) that we might
>> be able
>> to safely allow.  The reason it's entirely disabled is because we know
>> some
>> parts are unsafe, and sadly we didn't have the time/resources to sort out
>> which parts are which. :/
>
> I thought that the Tor project team had already a strong knowledge of
> WebRTC since recently we saw that the future might be flashproxy
> combined with uProxy (then WebRTC) to do something unstoppable.
>
> Some time ago I made [1], this drawing is supposed to explain simply how
> WebRTC works and at that time just leaded to the conclusion that the
> signaling servers are the perfect MITM and that the STUN servers can
> correlate the connections, then the IPs.

You forgot to give the url.

>
> But the signaling servers are not mandatory finally, WebRTC peers can
> introduce each others, but you still need some servers accessed usually
> via WebSockets to bootstrap the process, these are the concepts of
> projects like Peersm (which at the same time solves the issue of WebRTC
> DTLS self signed certificates) and WebTorrent.
>
> I did not study it deeply but in the strict context of the current Tor
> Browser, I think that nothing is safe in WebRTC, and it should be
> entirely disabled.
>
> Another more interesting idea that I have repeatedly posted without
> getting any feedback would be to allow to set the browser's proxy to an
> interface, like WebSockets or WebRTC.
>
> Example: let's take the proxy auto config mechanism, the pac file (let's
> forget about the security aspects to retrieve it here) which contains
> findproxyforurl is sandboxed and executed inside browsers, it is called
> by the proxy and returns an url.
>
> Instead of returning an url, you could have the Tor protocol inside the
> pac file (so sandboxed too) and it could return an Object, the Tor
> protocol would establish circuits via WebSockets or WebRTC with the Tor
> network or between browsers, the proxy would use the Object to write to
> those circuits and read from them (like a duplex stream
> proxy.pipe(Object).pipe(proxy))
>
> The interest would be to have Tor on any device, I am not saying that
> the pac file could be a solution, that's just an example of how this
> could work based on what exists today, now still remains the issue of
> implementing all of what the Tor Browser is doing, but it's still
> interesting to study, it certainly applies to projects mentioned above
> and plenty of others, now or later.
>

-- =

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

