Re: [rtcweb] Security implications of host candidates

[Justin Uberti <[e-mail]>]

On Sun, Jul 8, 2018 at 11:35 PM Martin Thomson <[e-mail]>
wrote:

> On Sat, Jul 7, 2018 at 5:36 AM Justin Uberti
> <juberti=[e-mail]> wrote:
> > 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.
>
> This seems like a fair analysis.  I read the draft and thought a
> little about this angle, and I think that it's worth doing something
> about, even if I'm not 100% sure of what that would look like.
>
> Other signals, like sharing an address, don't seem to be as reliable
> as this.  For instance, having to go to a NAT hairpin might add enough
> additional latency that it looks like you are on the same network, but
> not necessarily the same machine.  That might be enough information
> for a tracker, anyway, so that's a big caveat on any mitigation we
> come up with.
>

I did some more testing in http://jsfiddle.net/juberti/8n9p5jxk/ (hairpin
tester) and NAT hairpin doesn't always add significant latency. Obviously
it depends a lot on your wifi, but I was able to get 2-3 ms RTT for hairpin
on Ethernet and 6-8 ms RTT for wifi.

Basically, the site can try to connect two contexts via:
a) [existing] public IPv4 (indicates "same network")
b) [existing] IPv6 (indicates "same endpoint")
c) [existing] user-agent (indicates "same OS, same browser, same version")
d) [existing] fonts, gpu, display resolution, etc
e) [new] RTT < 5ms (indicates "probably same machine")

As such, e) doesn't add a lot, and as noted above, has false positives and
likely false negatives.

I'm not sure that what is proposed (limiting to a top-level browsing
> context that isn't also private browsing) is the best way to achieve
> the stated policy goals in the draft.  And more fundamentally, there
> are probably several policies that browsers might reasonably adopt
> along those lines.
>
> For instance, we might reasonably be similarly concerned about
> different unrelated top-level browsing contexts using this to link
> each other.  I know that Tor Browser would be concerned about this
> sort of isolation as much as it would worry about iframes on different
> pages.
>
> The best idea I have there is to fail resolution for .local names that
> the browser itself has minted for other origins[1].  That way,
> connections that are cross-origin and same-host would always at least
> hit a hairpin or relay.  Of course, failing resolution so quickly
> might leak information, so additional caution might be necessary (I
> don't think that it does, provided that a candidate is not entered
> into a checklist before resolution occurs, but I'm not sure how that
> would be implemented).
>

If we decide to take action here, this seems like a reasonable approach.
You'd still be able to link cross-browser usage, but not cross-context
(intra-browser) usage.

>
> This suggests that you could share mDNS names for frames under the
> same top-level browsing context without leaking more information,
> which could be very useful.
>
> (The data channels thing isn't relevant here, because measuring
> connection setup should be enough to link two browsing contexts.  RTP
> likely works as well, but it's less easy to use.)
>
> [1] The draft uses the term "execution context" here, which is
> probably the right phrase, but it's not really defined.
>