Delivery-Date: Thu, 29 Jan 2015 17:36:38 -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_ADSP_CUSTOM_MED,
	DKIM_SIGNED,FREEMAIL_FROM,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 981271E0A1C
	for <archiver@seul.org>; Thu, 29 Jan 2015 17:36:36 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 5575E2FFC9;
	Thu, 29 Jan 2015 22:36:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 71A2730087
 for <tor-talk@lists.torproject.org>; Thu, 29 Jan 2015 22:36:28 +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 WPw8etzkA39C for <tor-talk@lists.torproject.org>;
 Thu, 29 Jan 2015 22:36:28 +0000 (UTC)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com
 [IPv6:2a00:1450:400c:c05::234])
 (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 3ABD92FFE6
 for <tor-talk@lists.torproject.org>; Thu, 29 Jan 2015 22:36:28 +0000 (UTC)
Received: by mail-wi0-f180.google.com with SMTP id h11so31300106wiw.1
 for <tor-talk@lists.torproject.org>; Thu, 29 Jan 2015 14:36:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=message-id:date:from:user-agent:mime-version:to:subject:references
 :in-reply-to:content-type:content-transfer-encoding;
 bh=Pd6P0h6lRWSGN7MJreyrkqa4SWNh6HU7QoQSSn7OU9Y=;
 b=bKa51QgYfbNaMtCEsJ7WqH4t+AvnatD/oTTREO+e3Z0FOikeA0y63NsK1cLyyt6jZd
 LOSpH/fknxEBskc0IDGu7fRmPJf1vSphJNH5tXCE7tXhFoxdhLIe651iyblbnE3+cGMu
 YkJUZCSwFktgyKBHDZp6BFy46NAU+C7Rj+xCdSOIeMvOBNfJis1MZjztQw/Rlfz4JIld
 ycZveMqBvnwX/UcecBXHzz2kTuvsbHmpSRX3kbPYQ4Ua2YYknzNR9e/5BCJYF76z6LrV
 vA8N/r81mHEW/kWUj1WDkRF0QrGRuQldRwibkcmtx3L8gM433ddhAdmL4LBu8hiDygPM
 wpOw==
X-Received: by 10.181.8.98 with SMTP id dj2mr4256403wid.81.1422570985271;
 Thu, 29 Jan 2015 14:36:25 -0800 (PST)
Received: from [192.168.1.11] (ANice-652-1-19-126.w83-201.abo.wanadoo.fr.
 [83.201.30.126])
 by mx.google.com with ESMTPSA id vh8sm12246216wjc.12.2015.01.29.14.36.23
 for <tor-talk@lists.torproject.org>
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Thu, 29 Jan 2015 14:36:24 -0800 (PST)
Message-ID: <54CAB5E7.8020501@gmail.com>
Date: Thu, 29 Jan 2015 23:36:23 +0100
From: Aymeric Vitte <vitteaymeric@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3;
 rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: tor-talk@lists.torproject.org
References: <CAMCPh3yW-1mqmTsiA0vW9ipBpuovWZ06EraNo-bDodSV1=hdbQ@mail.gmail.com>
 <20150129212015.GJ6456@patternsinthevoid.net>
In-Reply-To: <20150129212015.GJ6456@patternsinthevoid.net>
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>


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 so=
me
> 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.

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.

-- =

Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

-- =

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

