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@gmail.com:

On 22 Feb 2016, at 09:52, Jose Carlos Norte jcarlos.norte@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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions