Slashdot Mirror
HTTP GZIP Compression Leaks Data On the Location of Tor Web Servers
An anonymous reader writes: The GZIP compression format includes a field in its header that shows the Web server's local date, at which the data was gzipped. Almost all Web servers use "zeros" to pad this field by default, citing performance issues. Around 10% of Tor site operators have removed this feature and are printing the packet's compression date. Unknown to them, this "server local date" leaks the Tor site's timezone which law enforcement can then narrow down to a specific geographical area. Coupled with other Tor protocol leaks, this could help deanonymize .onion sites.
RFC1952 clearly states that the mtime header is a POSIX timestamp, i.e., it is in universal time and not local time. The author of TFA somehow either completely missed or neglected to mention the fact that, per spec, there is no leakage of the timezone, and in fact two of his examples demonstrate exactly that.
Of the three examples cited in TFA, two of them - reddit.com and instagram.com - follow the spec and use POSIX time. Just run the php tool from TFA and you'll see that the time returned matches the current UTC time. Those servers aren't leaking their location because they follow the spec.
Only one example - bing.com - uses something other than POSIX time. Surprise surprise, some Windows-based server - presumably IIS? - ignores the standard and leaks the timezone in the process.
Now the question is, are people seriously running TOR hidden services on Windows machines? That just seems like asking for trouble. The operational security requirements of TOR hidden services are significantly higher than your average server, and I bet the chances of screwing that up with a Windows server are much higher. Leaking the timezone is probably the least of your worries in that case.
TL;DR Some Windows web server mis-implements the gzip standard and leaks the local timezone in the process. Spec-compliant web servers are not affected. TFA mis-identified two compliant servers as being affected. TFA did not list any Tor hidden services that are affected to allow for confirmation. This is mostly a non-issue.
but there's no way you'd want to be using your own exit node if you wanted the protection of TOR.
And using someone else's exit node to access your own VPN is also a bad idea.
Why should it change?
It's bad enough that any encrypted zip files get bullshit corruption error messages on windows XP and AES encrypted zip files get bullshit corruption error messages on newer versions of windows (see also the bullshit error messages you get when you try to use XP/IE on an HTTPS server configured with modern TLS ciphers, jesus fucking christ Microsoft, can't you just write "this file/website uses a newer, more secure protocol than this version of windows supports upgrade now to windows 10 WINDOWS 10 WINDOWS 10!!!1! I mean, fuck, you might actually convince someone to switch that way...)
*cough* sorry about that. Anyway, we've got bzip2 and now xz (same algorithm as 7zip) if you want your incompatible next version of gzip.