W3C home > Mailing lists > Public > public-web-security@w3.org > October 2011

Re: Security implications of network timing

From: Billy Hoffman <billy@zoompf.com>
Date: Tue, 4 Oct 2011 18:16:11 -0400
Message-ID: <CAH0WLwNw72zF+goWb6vaCRUW74v+wXWymazcMRn1XMWE2aOfzg@mail.gmail.com>
To: Tony Gentilcore <tonyg@chromium.org>
Cc: public-web-security@w3.org
The performance timing information in the new API has implications fat
beyond Felton's classic work on browser or shared cache snooping. I
see this facilitating some major advances in the JavaScript port
scanning that myself, Robert Hanson, and Jeremiah Grossman explored in
2006. We had to use crude setTimeout's/image.onerror/image.onload to
exfiltrate data about Intranet systems.The finer-grain information
about DNS look ups and TCP connections will make this much worse.


The perf guy in me love it. The whitehat in me hates it.

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 Tue, Oct 4, 2011 at 7:54 AM, Tony Gentilcore <tonyg@chromium.org> wrote:
> Hi Security Gurus,
> The Resource Timing[1] specification has just entered last call phase. It
> provides network timing details for each subresource loaded by a page,
> to wit, the HTTP redirect, DNS, TCP connect, HTTP request and HTTP
> response phases.
> We suspected that exposing this additional detail could improve the
> effectiveness of timing attacks like those described by Felten and
> Schneider[2]. So we have speculatively guarded these times with a
> same-origin restriction.
> But even with the same-origin restriction, other folks have
> speculated[3] these times could be used to improve the effectiveness
> of statistical fingerprinting. At the same time, developers who want
> to use the feature are concerned that the same-origin restriction is
> too crippling for their use-cases.
> So, we'd like to take a step back and develop a list of novel attacks
> that could be enabled by exposing network timing. Then we can put in
> the proper set of restrictions to prevent them. The problem is that
> none of the web performance working group participants have expertise
> in security or privacy.
> Are there folks in this group who would be willing to help us generate a list
> of novel attacks that could be exposed by network timing?
> Thank you,
> Web Performance Working Group
> [1] http://w3c-test.org/webperf/specs/ResourceTiming/
> [2] http://sip.cs.princeton.edu/pub/webtiming.pdf
> [3] http://lists.w3.org/Archives/Public/public-web-perf/2011May/0102.html
Received on Wednesday, 5 October 2011 07:42:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:19 UTC