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

[Eric Rescorla <[e-mail]>]

On Fri, Jul 17, 2015 at 10:51 AM, Daniel Roesler <[e-mail]> wrote:

> On Sun, Jul 12, 2015 at 1:15 PM, tim panton <[e-mail]> 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.


Rather than trying to decide who's responsibility this is, I suggest it
would be
more productive to ask whether there's some way for the browser to determine
whether the VPN has been configured in this way. If there is, then I at
least
would be willing to investigate whether it's possible for the browser to
behave differently in these cases.

For starters, I would ask what netstat -rn shows in these cases.



> On Mon, Jul 13, 2015 at 11:54 AM, Timothy B. Terriberry
> <[e-mail]> 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.


This wouldn't address your issue, because this is under *API* control.
the purpose of this section is not to protect the user from the site but
rather to allow the site to provide privacy features for the user.


-Ekr