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

[Tim Wilson-Brown - teor]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-onions/attachments/20160222/ee2e508f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-onions/attachments/20160222/ee2e508f/attachment.sig>