Re: [rtcweb] Security implications of host candidates

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
>
>
>