[tor-onions] HTTP GZIP Compression remote date and time leak

[Jose Carlos Norte]

Hi Tim,

Its interesting to know that this issue has been taken into account into
the TOR protocol itself. Clock skew and similar attacks are a serious issue
for anonymous services.

To provide additional information, I have found that only Microsoft Windows
Operating Systems are providing local times instead of universal times in
the MTIME field of the gzip header. The gzip specification states that only
universal times should be used, as you can see here:

http://www.zlib.org/rfc-gzip.html#header-trailer

However, for some reason, microsoft windows or some gzip implementation in
some popular web server for Microsoft Windows is not respecting the
specification and is using local times instead of universal times.

Of course, any implementation leaking time is susceptible to clock skew
attacks, even if they use universal time instead of local time. But those
implementations wrongly sending local times instead of universal times are
leaking a lot more information (i.e. the time zone where the service runs).


2016-02-22 0:22 GMT+01:00 Tim Wilson-Brown - teor <teor2345 at gmail.com>:

>
> On 22 Feb 2016, at 09:52, Jose Carlos Norte <jcarlos.norte at gmail.com>
> wrote:
>
> The gzip compression format used by HTTP if accepted by both server and
> client, under certain configurations, provides the date of the server that
> compressed the HTTP Response. This information can be used by a third party
> to know the time zone where the onion site is hosted.
> I have written a more in depth explanation about the topic at:
> http://jcarlosnorte.com/security/2016/02/21/date-leak-gzip-tor.html
> A proof of concept is included, to check if your service is leaking this
> information through the gzip headers of a compressed HTTP Response.
> I have decided to share this because is not an obvious miss-configuration
> that could lead to the leak of information about the physical position of
> your hidden service. Be careful.
> Of course, just knowing the timezone of your hidden service server is not
> enough to know your identity, or your exact server location, but combined
> with another leaks or other pieces of information, could be dangerous.
>
>
> Thanks for this report, Jose Carlos.
>
> For completeness, tor itself does not suffer from this issue, even though
> it uses gzip compression internally to compress directory documents.
>
> Hidden services and clients do not produce or recompress directory
> documents, so they could never be affected.
>
> And tor authorities use deflateInit2 to initialise compression for votes
> and consensuses, which zeroes the gzip header.
>
> From the deflateInit2 documentation in zlib.h:
>
>     "windowBits can also be greater than 15 for optional gzip
> encoding.  Add
>    16 to windowBits to write a simple gzip header and trailer around the
>    compressed data instead of a zlib wrapper.  The gzip header will have no
>    file name, no extra data, no comment, no modification time (set to
> zero), no
>    header crc, and the operating system will be set to 255 (unknown).  If a
>    gzip stream is being written, strm->adler is a crc32 instead of an
> adler32."
>
>
> Tim
>
>
> Tim Wilson-Brown (teor)
>
> teor2345 at gmail dot com
> PGP 968F094B
>
> teor at blah dot im
> OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
>
>
> _______________________________________________
> tor-onions mailing list
> tor-onions at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-onions/attachments/20160222/e729a66c/attachment.html>