Re: Security implications of network timing

> FWIW, I looked at this before, and I would be somewhat surprised if
> the API has any privacy consequences that extend beyond the current
> timing capabilities available to JavaScript and malicious servers.

I'm not sure that is true. Two thoughts:

1- Web performance timings will allow direct queries of the browser/OS
DNS cache separate from checking if a resource is in the browser cache
or shared cache. I am unaware of any method to do this now in
JavaScript, though there might be some way to do this in Java over a
LiveConnect bridge.

2- I don't see any definitions in the spec about what happens when
connecting to other ports/non-HTTP data. What does the performance
timing data for http://intranet:22/ look like? Specifically the TCP
connection info. Current JavaScript port scanning tricks are crude and
prone to false positives and false negatives when talking to non-HTTP
services. Be interesting to see if this improves the accuracy of this.
Also, the is little information about Timing-Allow-Origin behaves when
connection errors occur.

> suspect the key reason why it makes people uncomfortable is its
> explicit nature; and the fact that its introduction will essentially
> burn any bridges should we want to mitigate timing vectors in the
> future. Which may be a legit concern, though I don't see such
> mitigations happening soon.

I think this is very true.

--
Billy Hoffman
Founder and CEO,
Zoompf - Making Websites Faster
Phone: +1 (404) 509-0051
Cell: +1 (404) 414-2000
Get your free web performance assessment today at zoompf.com/free



On Fri, Oct 7, 2011 at 12:16 AM, Michal Zalewski <lcamtuf@coredump.cx> wrote:
>> For another vector, how about using the performance data to perform
>> geolocation testing?  I'm being totally theoretical with no PoC to back this
>> up but could the timing information help an attacker to better pinpoint
>> coordinates more accurately than geolocation databases today? I'm assuming
>> something like multilateration might be used, where the attacker controlled
>> various receivers, thereby controlling the cross-origin restriction as well.
>
> The attacker controlling several servers can already measure RTTs (and
> the number of hops, and many other parameters) very accurately simply
> by benchmarking HTTP connections.
>

>
> /mz
>

Received on Saturday, 8 October 2011 13:56:45 UTC