Re: [rtcweb] Please require user consent for data channels

Daniel Roesler <diafygi@gmail.com> Fri, 17 July 2015 17:52 UTC

Return-Path: <diafygi@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6AE1ACDC0 for <rtcweb@ietfa.amsl.com>; Fri, 17 Jul 2015 10:52:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level:
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cQ3PL25URcW for <rtcweb@ietfa.amsl.com>; Fri, 17 Jul 2015 10:52:24 -0700 (PDT)
Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217BB1ACDB4 for <rtcweb@ietf.org>; Fri, 17 Jul 2015 10:52:24 -0700 (PDT)
Received: by qged69 with SMTP id d69so21168247qge.0 for <rtcweb@ietf.org>; Fri, 17 Jul 2015 10:52:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zEpoI7049JAcCQ6L27qJyevtY5eo0kSny8ZDxyg7YBw=; b=P/MEHBRl+MRa2CSId/KCheii45eV/FzB+1ezGbAbVvjl5hgscgjE1+cXjbPTfs/Otn PjlCaRkh0lEua3AE6/5DZkBI9QVdaanpVhgzbldu8cAkAobPLVnbTU24mveswf1CLUsa XbswioKAd0T8Qz05fy9m3VCd0MiHb1qjvwfvJ91WkEMRI0o9jLoROkOH6tIuLVTDIfv9 moednkFzXx5TZ58Ovh+T9pnlojnXur2PoqlojQFxL9qtITKi/kfdX6U+KvTElTl3dzJQ /eydpTEuf4zaaNTPRDKdcGPWnuCxIMJVIlkjFT/0WDILksGEdwtoMr0Io5vETUlye2wn 6v1w==
X-Received: by 10.55.17.197 with SMTP id 66mr27642429qkr.90.1437155543375; Fri, 17 Jul 2015 10:52:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.108.130 with HTTP; Fri, 17 Jul 2015 10:51:53 -0700 (PDT)
In-Reply-To: <55A4097F.3060106@mozilla.com>
References: <CA+65OspMD_PVjk0BXh7t4LtjmFDcDatoeNjFQOO_OVtC-Br+OA@mail.gmail.com> <55A22A1B.4000202@gmail.com> <CA+65OspKCvwFh0GebiuUrhdtaL9zxYKLw04HdKEfewLCWQ+ZpQ@mail.gmail.com> <804017F1-0211-43F0-9CE3-1F51A9C9E705@lurchi.franken.de> <55A4097F.3060106@mozilla.com>
From: Daniel Roesler <diafygi@gmail.com>
Date: Fri, 17 Jul 2015 10:51:53 -0700
Message-ID: <CA+65OspX8L1vB_Q5VJ+P3GqJ7Z0H_xyPfzMu-S=FVLv7Ho4TdQ@mail.gmail.com>
To: "Timothy B. Terriberry" <tterriberry@mozilla.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/qqzJpSYDvJZYOnye9Pr6szgnSF8>
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Please require user consent for data channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jul 2015 17:52:26 -0000

On Sun, Jul 12, 2015 at 1:15 PM, tim panton <tim@phonefromhere.com> wrote:
>
> The problem is that those VPNs are misconfigured.
>

It appears that both built-in L2TP and PPTP VPN options for OSX cannot
be configured to hide the real IP address from WebRTC, even if you
select the option to route all traffic through the VPN[1]. You need to
install an OpenVPN client like Tunnelblick in order to hide your real
IP from WebRTC. As soon as I get some time on a Windows box, I'll
investigate the default behavior there.

[1]: https://i.imgur.com/Hyq1zLz.png

Since this is the behavior for built-in VPN options, and even if you
select the "send all traffic over VPN" setting, I disagree with the
sentiment that it's the user's fault or that the VPN has been
misconfigured. WebRTC should assume default behavior for operating
system VPN behavior and apply additional security steps to protect the
user when the operating system falls short. Blaming the operating
system is no excuse when you know the problem exists and you have the
means to protect the user.


On Mon, Jul 13, 2015 at 11:54 AM, Timothy B. Terriberry
<tterriberry@mozilla.com> wrote:
>
> These issues are all detailed in
> <https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch>. I would
> encourage those participating in this thread to read that document. We could
> always benefit from additional review.

-------<snip from Section 5.4>-------
   API Requirement:  The API MUST provide a mechanism to allow the JS to
      suppress ICE negotiation (though perhaps to allow candidate
      gathering) until the user has decided to answer the call [note:
      determining when the call has been answered is a question for the
      JS.]  This enables a user to prevent a peer from learning their IP
      address if they elect not to answer a call and also from learning
      whether the user is online.
-------</snip from Section 5.4>-------

I'd like to request that "suppress ICE negotiation (though perhaps to
allow candidate gathering)" be changed to "suppress ICE negotiation
and candidate gathering". That would be enough to require user consent
before local and VPN IP addresses are gathered.

Daniel