Re: [rtcweb] Security implications of host candidates

> It sorta feels like a same origin policy on the data channel might help.

This would break use cases like WebTorrent, and many other Decentralized
Web projects that utilize the data channel to send data between cooperating
pages hosted on different origins. Also, as Justin pointed out, this
doesn't solve the issue since two pages on the same origin but in different
browsing contexts could still communicate.

Feross

I write at feross.org and tweet as @feross <https://twitter.com/feross>.
I work on WebTorrent <https://webtorrent.io/>, Standard
<https://standardjs.com/>, and Study Notes <https://www.apstudynotes.org/>.

On Fri, Jul 6, 2018 at 12:35 PM Justin Uberti <juberti=
40google.com@dmarc.ietf.org> wrote:

>
>
> On Fri, Jul 6, 2018 at 10:53 AM westhawk <thp@westhawk.co.uk> wrote:
>
>> I think perhaps we should step back and see if we can block the threat
>> earlier on.
>>
>> If I understand correctly the issue is that 2 pages of different origin
>> could include 3rd party
>> javascript that connects to a web service to exchange OA and establish a
>> data channel
>> between the pages. It then looks at the latency and figures out that the
>> two are on
>> the same network/device.
>>
>> Is there a way we can make this prohibitively expensive or inaccurate?
>>
>> It sorta feels like a same origin policy on the data channel might help..
>> -Perhaps sign the webRTC certificates with the origin and have DTLS
>> refuse a handshake if
>> the two ends don’t have a common signature.
>>
>
> The issue is that two pages (probably of the same origin) can determine
> that they are on the same host even when running in different browsing
> contexts (e.g., one being in private browsing mode), by establishing a p2p
> connection and measuring latency.
>
> The key questions are a) whether this gives up information that is not
> already present (e.g., by looking at your own IPv6 address), and b) what
> mitigations might exist.
>
> We'll have some time to discuss in Montreal.
>
>
>> I’m obviously very keen to avoid forcing all data channel traffic through
>> TURN.
>>
>
>>
>>
>> On 6 Jul 2018, at 18:15, Justin Uberti <
>> juberti=40google.com@dmarc.ietf.org> wrote:
>>
>> Thanks for the new version. I tried a few scenarios and agree that this
>> technique can identify a same-host situation fairly reliably, especially in
>> wireless environments; I typically saw ~2 ms latency for same-host and 5-10
>> ms latency (with occasional spikes) for over-the-air connections.
>>
>> I'm still not quite sure what we should do about it; as noted, public
>> IPv4 + user-agent (http://www.whatsmyua.info/) is probably unique in the
>> vast majority of cases, and the situation is unavoidable with IPv6.
>>
>>
>>
>> On Wed, Jul 4, 2018 at 2:12 PM youenn fablet <youennf@gmail.com> wrote:
>>
>>>
>>> Le mar. 3 juil. 2018 à 14:40, Justin Uberti <juberti@google.com> a
>>> écrit :
>>>
>>>> Updated fiddle (outputs to display as well as console):
>>>> https://jsfiddle.net/juberti/x7a8ut0q/37/
>>>>
>>>
>>> Right, this shows the local loopback latency.
>>>
>>>
>>>> On Tue, Jul 3, 2018 at 11:16 AM Justin Uberti <juberti@google.com>
>>>> wrote:
>>>>
>>>>> I wasn't able to get that example to work (tried with 2 Chrome and 2
>>>>> Safari instances, got a setRemoteDescription error both times), but I was
>>>>> able to make a JSFiddle <https://jsfiddle.net/juberti/x7a8ut0q/25/>
>>>>> which does something similar in a single page. At present, even host-host
>>>>> connections were seeing a 2 ms RTT, possibly because of the clamping
>>>>> <https://developer.mozilla.org/en-US/docs/Web/API/Performance/now>
>>>>> that has been applied to performance.now() to deal with Spectre et al.
>>>>>
>>>>
>>> I updated
>>> https://evening-thicket-98446.herokuapp.com/src/content/peerconnection/datachannel-b2b/,
>>> it should hopefully be more intuitive to use this time:
>>> 1. load the page in one device
>>> 2. load the link provided by the page on another device
>>> 3. click 'call' on the first page
>>> 4. a latency value should appear on the page and be continuously updated
>>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>