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

On Fri, Jul 17, 2015 at 2:03 PM, Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

>  Hi Justin,
>
> Thanks for pointing that out, can you point me were in RFC5245 is that
> behavior described? I fail to find it.
>
> The only references I found about multihoming are about HOST candidates,
> performing connectivity checks and priorization of candidates, but I cannot
> find a reference on sending STUN request to the TURN/STUN server via all
> the available interfaces in order to retrieve the server reflexive
> candidates that is where the leak is originating. Please correct me again
> if I am wrong.
>

Section 2.1, paragraphs 2 and 3 talks about getting all interfaces, and
then getting STUN and TURN candidates from said interfaces.

>
> Anyway, this raises another attack vector, as the IP may be leaked not
> directly via the ICE reflexive candidates, but via the connectivity checks.
> That is, the "malicious" server may just not get the IP via the server
> reflexive candidates, but doing an SDP O/A with remote ice candidates of a
> fake ICE server, that correlates the STUN connectivity checks with the web
> visit (via ice username for example).  They don't even need a STUN/TURN
> server deployed.
>
> Best regards
> Sergio
>
>
> On 17/07/2015 22:25, Justin Uberti wrote:
>
> What you describe is the proper operation of RFC5245, so this isn't a
> Chrome implementation decision (Firefox behaves the same way, and I assume
> Edge will as well).
>
>  However, we have been thinking about whether refinements to the
> behaviors specified in RFC5245 are warranted in the web context.
>
> On Fri, Jul 17, 2015 at 12:11 PM, Sergio Garcia Murillo <
> <sergio.garcia.murillo@gmail.com>sergio.garcia.murillo@gmail.com> wrote:
>
>>  If I have understood the looong thread correctly, the issue is that
>> Chrome overrides the OS default route and sends the STUN requests via all
>> available interfaces, therefore leaking the IP addresses on the process.
>>
>> AFAIK, that behavior is a Chrome implementation decision (wrong in my
>> opinion, but understandable) and it is not specified on WebRTC, so while
>> acknowledging the importance of the issue, this is not something that we
>> should discuss in this mailing list, except if we decide that we should
>> decide to explicitly forbid this behavior and add it to the security draft.
>>
>> I will send a reply to discuss-webrtc to continue the discussion from a
>> Chrome point of view.
>>
>> Best regards
>> Sergio
>>
>>
>> On 17/07/2015 20:36, Justin Uberti wrote:
>>
>> The title is somewhat inaccurate, but
>> https://code.google.com/p/chromium/issues/detail?id=457492 is the
>> current bug for this.
>> See also https://code.google.com/p/chromium/issues/detail?id=333752,
>> from which the above bug was spun out.
>>
>> On Fri, Jul 17, 2015 at 11:22 AM, Daniel Roesler < <diafygi@gmail.com>
>> diafygi@gmail.com> wrote:
>>
>>> On Fri, Jul 17, 2015 at 11:04 AM, Justin Uberti <juberti@google.com>
>>> wrote:
>>> >
>>> > This is already possible using non-WebRTC technologies, e.g. web
>>> sockets. As
>>> > such, I don't think that permission should be needed to create a data
>>> > channel, or receive (but not send) media.
>>> >
>>>
>>> The big difference is that Web Sockets starts off with an HTTP
>>> request, so it can be filtered by various plugins (PrivacyBadger,
>>> uBlock, Ghostery, etc.). WebRTC is invisible to those services since
>>> it does not have any HTTP requests at all. In fact, is WebRTC the only
>>> browser standard (i.e. not flash) that can fire off a DNS request
>>> that's not (at least at first) for an HTTP address[1]? Lacking an
>>> initial HTTP request makes it impossible for plugins to selectively
>>> filter these requests, so they have to fall back to an all-or-nothing
>>> config setting approach (which hurts WebRTC adoption in
>>> general)[2][3].
>>>
>>> > That said, I agree that WebRTC should not allow drive-by harvesting of
>>> IP
>>> > addresses, and we intend to make changes to Chrome to prevent this.
>>>
>>> Great to hear! Thanks! Is there a bug that is tracking this?
>>>
>>>
>>> [1]:
>>> https://www.w3.org/wiki/Privacy/IPAddresses#Using_wildcard_DNS_entries_as_persistent_identifiers
>>> [2]: https://github.com/EFForg/privacybadgerfirefox/issues/394
>>> [3]: https://github.com/gorhill/uBlock/releases/tag/0.9.9.3
>>>
>>> Daniel
>>>
>>
>>
>>
>>  _______________________________________________
>> rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>
>