HTTP GZIP Compression Leaks Data On the Location of Tor Web Servers 79
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.
And there you are... (Score:2)
Tor is looking more and more "holey" all the time.
I can't help but wonder if the recent glibc DNS issue is not also an help in this deanonymization.
It seems to me there are less and less possibilities to escape the global panopticon.
Re: (Score:1)
Hey! An Apple user!
Re: (Score:2)
No one understands security, so don't implement any?
Seems plausible. Still, something seems odd about that argument ... Can't quite put my finger on it.
Not nothing-- everythings (Score:3)
This has nothing to do with Tor and has everything to do with incompetent sysadmins.
And if the sysadmins of Tor nodes are incompetent, it has everything to do with Tor.
Re: (Score:3)
Re: (Score:2)
Tor Web servers are like ogres?
Re: (Score:1)
So you can't figure out how to rent an anonymous VPS and use SSH over tor to port forward out through the VPS?
Re:And there you are... (Score:5, Insightful)
find a way to slap a VPN after TOR
You don't have any control over the "after TOR" side of the connection. You could slap a VPN before TOR, or operate an exit node that uses a VPN, but there's no way you'd want to be using your own exit node if you wanted the protection of TOR.
Re: (Score:2, Interesting)
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.
Re: (Score:3)
This is not a problem with Tor. This is the server operator failing to properly anonymize their server.
It's like if I go and download and use the Tor Browser, but then fall victim to a phishing scam and give out personal information while using it. Tor will anonymise your connection to websites perfectly fine, but you the user are leaking information about yourself and Tor can't do anything about that. This is the same kind of issue.
Re: (Score:3)
Re: (Score:2)
Yea because knowing the servers location at the resolution of a timezone will help a lot...
Re: (Score:3)
Yea because knowing the servers location at the resolution of a timezone will help a lot...
If the time zone is the Winamac time zone in Indiana, or some of the other very regional time zones, it may.
It's just another datum in fingerprinting, but in some cases, it may be the crucial one.
Re:And there you are... (Score:5, Insightful)
It could be more helpful than you think. If the server says its timezone is in the US, for example, that may be enough for a judge to grant the FBI a warrant authorizing god-knows-what attacks against it.
Re: (Score:2)
Oh, the FBI doesn't need that to get a warrant nowadays, they are happily hacking foreign servers too.
Re: (Score:3)
I see TOR kind of like HTTPS: it won't necessarily keep your transmission from being decrypted and deanonymized, but it probably makes it much harder to do so. As such it just sort of raises your default level of privacy (from plain HTTP).
Re: (Score:2)
Bullshit. TOR security is getting fine-tuned, that is all. Of course, no sane TOR site operator would configure the correct timezone...
Use a single timezone (Score:1)
Re:Use a single timezone (Score:5, Insightful)
Or just pad it with zero's like everything else does, apparently.
Better to go with the flow in this case instead of trying to be clever.
Re: (Score:3, Informative)
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
You should have countered that the GMT timezone uses the UTC time format. In essence GMT is defined as UTC+0. But I like the tiny fist of rage.
Not everything uses syslog (or even linux) and, believe it or not, I've seen people reconfigure systems to force the server to be in a specific timezone so that everything runs within that TZ, including logs. I think it's stupid, but I've seen it done. You can think of those people as belonging to "the world revolves around me" group.
Re: (Score:1)
NO.
There is no daylight savings time in UTC, while GMT enjoys an extra hour of daylight during the summer months...er :)
Re: (Score:3)
You're thinking of BST, GMT is constant and the uk switches to BST during the summer.
Re: (Score:1)
If you're not using Barycentric Dynamical time your system will not scale well to multiple planets.
When I'm fortunate enough to have to worry about that problem, I'll get right on it.
Re: (Score:3)
Or just pad it with zero's like everything else does, apparently.
Even better would be to fill it with a value for a randomly selected TZ. That way you are poisoning the data, so "they" cannot be sure if any TZ fields are valid.
Re:Use a single timezone (Score:4, Insightful)
Almost every attempt to poison data turns into another datapoint. That datapoint is likely more valuable than a NULL value.
For instance, that leaks data about your pseudo-random number generator, opens up timing based identification, etc.
Re: (Score:1)
Nope, use Stardates. That way the authorities need to check all of Federation Space for your hidden service.
It leaks the server's location (Score:5, Funny)
For very large values of location.
Re: (Score:1)
Meta data is in the meta. The time itself may not matter, but if you combine that with native language you can probably get to the country--particularly for English, Portuguese, and many of the smaller localized languages of eastern Europe, Africa, SE Asia. The one probably most difficult is Spanish since many countries that speak Spanish are in a vertical column (adjacent timezones) in the Americas (sorry Spain)
What the gzip spec says about MTIME (Score:5, Informative)
Relevant parts of the Gzip specification, RFC-1952:
2.3.1
MTIME (Modification TIME)
This gives the most recent modification time of the original
file being compressed. The time is in Unix format, i.e.,
seconds since 00:00:00 GMT, Jan. 1, 1970. (Note that this
may cause problems for MS-DOS and other systems that use
local rather than Universal time.) If the compressed data
did not come from a file, MTIME is set to the time at which
compression started. MTIME = 0 means no time stamp is
available.
7.
When compressing or decompressing a file, gzip preserves the
protection, ownership, and modification time attributes on the local
file system, since there is no provision for representing protection
attributes in the gzip file format itself. Since the file format
includes a modification time, the gzip decompressor provides a
command line switch that assigns the modification time from the file,
rather than the local modification time of the compressed input, to
the decompressed output.
Re:What the gzip spec says about MTIME (Score:5, Informative)
Vote parent up.
The article the summary references is just a summary of this: http://jcarlosnorte.com/securi... [jcarlosnorte.com]
In which, he notes:
Offset Size Value Description
0 2 0x1f 0x8b Magic number to idenitfy gzip streams
2 1 Compression method
3 1 Flags
4 4 Compression Date
8 1 Compression flags
9 1 Operating system
He references that as coming from: http://www.forensicswiki.org/w... [forensicswiki.org]
But that document does not say "Compression Date". It actually says:
4 4 Last modification time. Contains a POSIX timestamp.
Even his proof of concept shows that he's parsing that field as a POSIX timestamp: https://github.com/jcarlosn/gz... [github.com]
echo date('l jS \of F Y h:i:s A', $rdate);
It appears that either:
a) Something else in his php script is setting the TZ before doing that parse
b) The server is calculating the POSIX timestamp incorrectly, which is a similar issue but quite a different root cause.
Re:What the gzip spec says about MTIME (Score:5, Informative)
... just to confirm, the answer is "b": The server is calculating the POSIX timestamp incorrectly, which is a similar issue but quite a different root cause.
I updated his script to print the difference between the current POSIX timestamp and the value returned by the server.
bing.com: current - server_value = 28800
reddit.com: 0
instragram.com: 0
Those were his three tests. I'm not surprised the Microsoft server is the one calculating a POSIX timestamp incorrectly. MS folks tend to do timestamp math very poorly. I suspect this only affects Microsoft servers, or horribly misconfigured $anything_else.
undocumented gzip (Score:5, Informative)
There are undocumented gzip command line switches (-m, -M) that control embedding timestamps in gzip archives. They're not mentioned in the man page or --help output, but you can see them in the source here (line 344): http://git.savannah.gnu.org/cgit/gzip.git/tree/gzip.c [gnu.org]
#ifdef UNDOCUMENTED
" -m, --no-time do not save or restore the original modification time",
" -M, --time save or restore the original modification time",
#endif
I learned about this because I had to ensure consistent hash values of build artifacts for regulatory reasons and I believe it is a misfeature. For me the Principle of Least Surprise would have gzip produce this exact same output given the same input, by default. As it is you get a slightly different output each time you compress the same set of bits, and that is entirely down to this timestamp. I think the fact that switches to achieve that behavior exist yet are undocumented belies some conflict about this.
Re: (Score:1)
In the reproducible builds effort [reproducible-builds.org], "gzip -n" is the norm.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2, Interesting)
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
I'll take those odds (Score:2)
Re: (Score:3)
Exactly...
You would think nobody who decided to rob a bank would write the note on the back of mail addressed to themselves.
Hell you might think that nobody would think "hey, in this live production stock exchange trading system, lets try entering a value of -6"
Then you might think "Surely nobody developing a live production stock exchange trading system would ever simply cast a signed integer into an unsigned integer and allow a user to accidentally post a 69 trilliong dollar trade as a result?"
You would b
Not if they follow the spec (Score:5, Interesting)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
Still leaks information. Even if the time stamp is always in UTC, it remains possible to confirm the server is not traveling at a high enough relative relative to the requester to cause a difference in observed time.
This is serious folks, it likely means you can in fact determine the server to be on the same planetary body or even in the same orbit!
Re: (Score:2)
The transceiver in the NIC completely obliterates any data you can gather from relativistic effects in the delays it introduces in its own media converter to go from the chip to the wire line voltages.
False information (Score:2)
Or they can intentionally set their timezone to a different value to mislead...
Chances are of zeroes are the default and tor sites have explicitly turned this off, then that's exactly what they've done... People running sites via tor are likely to be privacy conscious, so if they've changed a setting to a non default value they probably did it for a reason.
Hide the offset, Use UTC exclusively (Score:1)
Hide the offset, Use UTC exclusively
Then again... (Score:2)
I usually set mine to UTC, no matter where they are.
For this kind of leak I might "accidentally-on-purpose" select a timezone the machine doesn't happen to be in.
Ummm, why run compression over the network? (Score:2)