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

[Sergio Garcia Murillo <[e-mail]>]

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.

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 
> <[e-mail] 
> <mailto:[e-mail]>> 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
>>     <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>         On Fri, Jul 17, 2015 at 11:04 AM, Justin Uberti
>>         <[e-mail] <mailto:[e-mail]>> 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 list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>     _______________________________________________
>     rtcweb mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>