HTTP GZIP Compression Leaks Data On the Location of Tor Web Servers

← Back to Stories (view on slashdot.org)

HTTP GZIP Compression Leaks Data On the Location of Tor Web Servers

Posted by timothy on Monday February 22, 2016 @03:43AM from the they're-around-here-somewhere dept.

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.

79 comments

Min score:

Reason:

Sort:

And there you are... by Noryungi · 2016-02-22 03:46 · Score: 1

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.

--
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
1. Re:And there you are... by Anonymous Coward · 2016-02-22 03:51 · Score: 0
  
  This has nothing to do with Tor and has everything to do with incompetent sysadmins. Security is a process, if you don't understand the process, don't try to fuck with things you don't understand.
2. Re:And there you are... by bugs2squash · 2016-02-22 03:57 · Score: 2
  
  You thought it was the onion ring because of the layers, no it's because of the hole in the middle.
  
  --
  Nullius in verba
3. Re:And there you are... by Anonymous Coward · 2016-02-22 03:59 · Score: 0
  
  It seems to me there are less and less possibilities to escape the global panopticon.
  Offline, with your cell phone stuffed into a tin box. Outside, hopefully out of range of the nearest public safety camera.
4. Re:And there you are... by vtcodger · 2016-02-22 04:01 · Score: 1
  
  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.
  
  --
  You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
5. Re:And there you are... by Anonymous Coward · 2016-02-22 04:10 · Score: 0
  
  Problem with Tor is that any site you visit that isn't a .onion site, usually blocks or severely limits what you can do. This is because exit nodes tend to be attack points.
  If someone can find a way to slap a VPN after TOR, that would be useful. You have real anonymity, but the website guardians don't show you the door for coming from skid row.
6. Re:And there you are... by Anonymous Coward · 2016-02-22 04:12 · Score: 0
  
  Who says I need to build one?
7. Re:And there you are... by Anonymous Coward · 2016-02-22 04:13 · Score: 1
  
  Hey! An Apple user!
8. Re:And there you are... by Anonymous Coward · 2016-02-22 04:16 · 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?
9. Re:And there you are... by The+MAZZTer · 2016-02-22 04:21 · Score: 2
  
  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.
10. Re:And there you are... by omnichad · 2016-02-22 04:43 · Score: 4, 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.
11. Re:And there you are... by Anonymous Coward · 2016-02-22 04:44 · Score: 0
  
  Tor is looking more and more "holey" all the time.
  That's why I only use it on Sunday.
12. Re:And there you are... by LWATCDR · 2016-02-22 05:29 · Score: 1
  
  Yea because knowing the servers location at the resolution of a timezone will help a lot...
  
  --
  See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
13. Re:And there you are... by pr0nbot · 2016-02-22 05:36 · Score: 2
  
  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).
14. Re:And there you are... by Anonymous Coward · 2016-02-22 05:39 · 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.
15. Re:And there you are... by arth1 · 2016-02-22 05:41 · Score: 2
  
  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.
16. Re:And there you are... by Motherfucking+Shit · 2016-02-22 05:55 · Score: 4, 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.
  
  --
  "BSD: Free as in speech. Linux: Free as in beer. Windows 10: Free as in herpes." --Man On Pink Corner in #52607549.
17. Re: And there you are... by Anonymous Coward · 2016-02-22 06:02 · Score: 0
  
  Us 7th Days use it on Saturday you insensitive bigot.
18. Re:And there you are... by U2xhc2hkb3QgU3Vja3M · 2016-02-22 06:20 · Score: 1
  
  Tor Web servers are like ogres?
19. Re: And there you are... by Anonymous Coward · 2016-02-22 07:40 · Score: 0
  
  Exactly! The headline should have been: "stupid people do stupid things". Wouldn't have changed a single fact of the story.
20. Re:And there you are... by mitcheli · 2016-02-22 08:05 · Score: 2
  
  Let's see... FBI takes over Onion servers, supposedly paid universities for "research", managed to find the operator to silk road 2.0, and managed a rather large bust of criminals. Then you've got the issue of "fake tor clients"... Seems to me that considering tor (be it with a VPN before or after) is really irrelevant and that the underlying technology of tor has just been under attack for two long and needs to be replaced.
  
  --
  Select from tblFriends where interesting >= 4;
21. Re:And there you are... by gweihir · 2016-02-22 08:44 · Score: 1
  
  Bullshit. TOR security is getting fine-tuned, that is all. Of course, no sane TOR site operator would configure the correct timezone...
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
22. Re:And there you are... by Anonymous Coward · 2016-02-22 10:35 · Score: 0
  
  Soon there will be no possibilities of escaping the global panopticon. In fact, I'd strongly advise you not to try anymore and to refrain from discussing the topic. It will only make a target of you.
23. Re:And there you are... by yacc143 · 2016-02-22 19:06 · Score: 1
  
  Oh, the FBI doesn't need that to get a warrant nowadays, they are happily hacking foreign servers too.
24. Re:And there you are... by Anonymous Coward · 2016-02-24 12:23 · Score: 0
  
  Bravo, send all our technologies for FREE abroad to just about any country, but here. If I d play Civilization that way...
25. Re:And there you are... by Anonymous Coward · 2016-02-27 02:41 · Score: 0
  
  It's doughnuts that have holes in the middle, not onions. You can make rings from onions, but that isn't how they come out of the ground.
  Perhaps you need a cookery course, so you can learn what food looks like before it is prepared for you.
Use a single timezone by Anonymous Coward · 2016-02-22 03:50 · Score: 1

Patch it to use the same time-zone (e.g. UTC+0)?
1. Re:Use a single timezone by The-Ixian · 2016-02-22 03:56 · 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.
  
  --
  My eyes reflect the stars and a smile lights up my face.
2. Re:Use a single timezone by Anonymous Coward · 2016-02-22 04:00 · Score: 1
  
  Nope, use Stardates. That way the authorities need to check all of Federation Space for your hidden service.
3. Re:Use a single timezone by Gr8Apes · 2016-02-22 04:10 · Score: 3, Informative
  
  All my servers are set to GMT. Why? Because when you're running across multiple TZs, it's a hell of a lot easier to trace logs when they use a single common global time. My activities don't care if they're in Asia/Tokyo, Europe/Berlin, Australia/Melbourne, or America/New_York, especially when services cross those regions.
  
  --
  The cesspool just got a check and balance.
4. Re:Use a single timezone by Anonymous Coward · 2016-02-22 04:11 · Score: 0
  
  The downside with zeroes is that an attacker can disregard them and use the field when available.
  If filled with a fake timezone value the attacker will not be able to distinguish if the value exists or not and the program you didn't know about that that puts the real date in the field will disappear in the noise.
5. Re:Use a single timezone by ShanghaiBill · 2016-02-22 04:25 · Score: 2
  
  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.
6. Re:Use a single timezone by dAzED1 · 2016-02-22 05:09 · Score: 0
  
  please tell me you're kidding. Do you not know what UTC is? Does your logging software not know what UTC is? I mean fark, syslog does utc by default, is this some stupid lennart poettering thing again? Did he re-write syslog because it didn't do message queueing, and now you can't turn on the kitchen sink without logstart running, and it doesn't know what UTC is?
7. Re:Use a single timezone by Anonymous Coward · 2016-02-22 05:19 · Score: 0
  
  Please tell me YOU are kidding? UTC is a time format which, by definition, uses the GMT timezone.
8. Re:Use a single timezone by dAzED1 · 2016-02-22 05:34 · Score: 1
  
  *shakes tiny fist of rage* Hmm, well, yeah, I guess there is that. However, GMT is an actual timezone, and while the numbers might look the same, they're not reached the same way - one is converted, the other is not. But yeah, fine....you win...*this* time. But I'll be watching you.
9. Re:Use a single timezone by Anonymous Coward · 2016-02-22 06:02 · Score: 1
  
  NO.
  There is no daylight savings time in UTC, while GMT enjoys an extra hour of daylight during the summer months...er :)
10. Re:Use a single timezone by Bert64 · 2016-02-22 06:31 · Score: 2
  
  You're thinking of BST, GMT is constant and the uk switches to BST during the summer.
  
  --
  http://spamdecoy.net - free throwaway anonymous email - avoid spam!
11. Re:Use a single timezone by Actually,+I+do+RTFA · 2016-02-22 08:00 · Score: 3, 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.
  
  --
  Your ad here. Ask me how!
12. Re: Use a single timezone by Anonymous Coward · 2016-02-22 08:08 · Score: 0
  
  If you're not using Barycentric Dynamical time your system will not scale well to multiple planets.
13. Re: Use a single timezone by Gr8Apes · 2016-02-22 08:43 · 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.
  
  --
  The cesspool just got a check and balance.
14. Re:Use a single timezone by Gr8Apes · 2016-02-22 09:00 · 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.
  
  --
  The cesspool just got a check and balance.
15. Re:Use a single timezone by Anonymous Coward · 2016-02-22 09:13 · Score: 0
  
  I stand corrected, thanks.
16. Re:Use a single timezone by Anonymous Coward · 2016-02-22 11:11 · Score: 0
  
  Let's not forget GPS time and TAI time as well, both within one minute of UTC, but off by 17 and 36 seconds respectively (currently).
It leaks the server's location by AmiMoJo · 2016-02-22 03:57 · Score: 5, Funny

For very large values of location.

--
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
1. Re:It leaks the server's location by Anonymous Coward · 2016-02-22 04:20 · Score: 0
  
  Not necessarily. Some non-integer-hour zones are pretty well-localized.
2. Re:It leaks the server's location by Anonymous Coward · 2016-02-22 04:55 · 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 by Anonymous Coward · 2016-02-22 03:57 · 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.
1. Re:What the gzip spec says about MTIME by unrtst · 2016-02-22 04:22 · Score: 5, Informative
  
  Vote parent up.
  The article the summary references is just a summary of this: http://jcarlosnorte.com/securi...
  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...
  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...
  
  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.
2. Re:What the gzip spec says about MTIME by unrtst · 2016-02-22 04:32 · 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.
3. Re:What the gzip spec says about MTIME by Anonymous Coward · 2016-02-22 04:57 · Score: 0
  
  So the HTTP GZIP Compression isn't blocking the local time information that the badly-configured server is leaking. This doesn't appear to be a problem with GZIP.
4. Re:What the gzip spec says about MTIME by DNS-and-BIND · 2016-02-22 06:29 · Score: 1
  
  Why has the GZIP specification not been updated since the era of MS-DOS? Seriously?
  
  --
  Shutting down free speech with violence isn't fighting fascism. It IS fascism!
5. Re:What the gzip spec says about MTIME by Anonymous Coward · 2016-02-22 07:07 · 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 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.
I'll take those odds by Big+Hairy+Ian · 2016-02-22 04:01 · Score: 1

So it's effectively 6 Billion divided by 24 and easily mitigated just set a different timezone if it's your server you're going in on or connect to a tor server in a different time zone.

--
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
Default Timezone by Anonymous Coward · 2016-02-22 04:02 · Score: 0

Pretty sure that if someone is running an anonymous server, for whatever purpose, they aren't going to fill in their location details accurately and just stick with the defaults. It's an interesting leak but it's a bit of a stretch to think this is a significant issue. Besides, it's been reported now, whatever leverage that could have given to law enforcement is basically zero now.
1. Re:Default Timezone by Anonymous Coward · 2016-02-22 04:12 · Score: 0
  
  Pretty sure that if someone is running an anonymous server, for whatever purpose, they aren't going to fill in their location details accurately and just stick with the defaults. It's an interesting leak but it's a bit of a stretch to think this is a significant issue. Besides, it's been reported now, whatever leverage that could have given to law enforcement is basically zero now.
  Meanwhile, here on Earth where people are idiots...
2. Re:Default Timezone by TheCarp · 2016-02-22 08:40 · Score: 2
  
  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 be wrong on all three, but, the first happened so many times you can find those for yourself:
  http://news.slashdot.org/story...
  
  --
  "I opened my eyes, and everything went dark again"
This just in, metadata is data by Anonymous Coward · 2016-02-22 04:03 · Score: 0

It's not a Tor problem, it's a metadata mindset problem.
Not if they follow the spec by marcansoft · 2016-02-22 04:09 · 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.
1. Re:Not if they follow the spec by bluefoxlucid · 2016-02-22 04:23 · Score: 1
  
  It makes for good television.
  
  --
  Support my political activism on Patreon.
2. Re:Not if they follow the spec by Anonymous Coward · 2016-02-22 04:30 · Score: 0
  
  Bing: not even once.
3. Re:Not if they follow the spec by jcarlosn · 2016-02-22 07:35 · Score: 2
  
  Hi marcan, nice to have you included in the discussion. I'm the author of the article. To be fair, the gzip specification was clear from the beginning. In fact I was reading this exact specification when I thought about the impact it could have on tor hidden services. The specification itself clearly states that there are potential problems with universal times under certain systems (i.e. MS-DOS at the time of the specification writing). I thought that maybe current implementations could be flawed, developed the little PoC and started doing tests in the wild. I found that a lot of servers were sending local times instead of unviersal times. The problem with this for me, is that even the universal time leak could be dangerous for hidden services. A lot of hidden services are filtering out 'Date' headers in their http responses in order to prevent getting information from their clock skew. So, yesterday I was with a PoC that was able to extract local time under certain conditions (conditions that I didn't understand clearly) and universal time (thus, clock skew) in other conditions. After discussing it with some friends related to the tor project, I decided that the best was to share it 'as-is'. Maybe further investigation could have been a good idea before sharing, but the possibility of this affecting hidden service privacy forced me to publish it 'as-is', even if further investigation was needed. Today, after a lot of research and help and comments from a lot of people I have better understood the problem and I still consider it a problem. We have found broken implementations of the gzip library under other operating systems than windows and of course, in the end this is a source of potential clock skew leak. So, I consider dangerous and irresponsible considering this a non-issue. I consider important for people managing hidden services to know that gzip is potentially leaking its clock skew, and potentially leaking its local time. I consider important that anyone that is filtering out, or disabling the 'date' header, also takes gzip into consideration. I think that this is just another example of how complicated is to setup a really anonymous hidden service and how even in the gzip stream there could leaks about your local time, or your clock skew. Openly discussing it is very interesting. What worries me is that I received a lot of feedback from people that is running hidden services that didn't knew that gzip was leaking any time information at all. You can read at reddit, or just here how people is surprised to read that in their gzip compressed data there is information about the time, operating system, etc. About your comments regarding why I didn't provide examples of affected hidden services, for me, it is not responsible to openly discussing a privacy issue like that while putting real people privacy at stakes. I consider that putting examples of hidden services compromised by this issue is not going to help in any way to better understand the potential impact of the information contained in a gzip header.
4. Re:Not if they follow the spec by Anonymous Coward · 2016-02-22 10:11 · Score: 0
  
  Consider using paragraphs. That was really tiring to read.
5. Re:Not if they follow the spec by DarkOx · 2016-02-22 10:25 · Score: 2
  
  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!
  
  --
  Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
6. Re:Not if they follow the spec by BitZtream · 2016-02-22 10:53 · Score: 1
  
  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.
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
undocumented gzip by TopSpin · 2016-02-22 04:32 · 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
#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.

--
Lurking at the bottom of the gravity well, getting old
1. Re:undocumented gzip by sanvila · 2016-02-22 07:29 · Score: 1
  
  You don't really have to bother with undocumented features.
  In the reproducible builds effort, "gzip -n" is the norm.
2. Re:undocumented gzip by DraconPern · 2016-02-22 10:00 · Score: 1
  
  I think it's because gzip only ensures the content stays the same. The archive itself can change from version to version or implementation to implementation.
3. Re:undocumented gzip by jrumney · 2016-02-22 17:29 · Score: 1
  
  I'd expect gzip to give you exactly the same output when run on exactly the same file each time. Only when you use it in a pipe (operating on stdin) should it use the current timestamp instead of the modification timestamp of the input file.
Not nothing-- everythings by XXongo · 2016-02-22 05:05 · Score: 2

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.
Asking for trouble by compressing? by Anonymous Coward · 2016-02-22 05:16 · Score: 0

Aren't you asking for trouble by compressing data and using HTTPS? My understanding was that BREACH was still a viable attack against TLS when using HTTPS. Seems to me that the last hop between you and the actual hidden service could use such an attack.
UTC by Anonymous Coward · 2016-02-22 05:18 · Score: 0

don't most servers use UTC TZ anyways?
"Law enforcement?" by Anonymous Coward · 2016-02-22 06:24 · Score: 0

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.
Law enforcement can use the information, but the other 99% of your adversaries can't?!
False information by Bert64 · 2016-02-22 06:28 · Score: 1

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.

--
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Hide the offset, Use UTC exclusively by Anonymous Coward · 2016-02-22 08:08 · Score: 1

Hide the offset, Use UTC exclusively
MAT by Anonymous Coward · 2016-02-22 08:08 · Score: 0

Maybe the Metadata Anonymization Toolkit could help with this. https://mat.boum.org/
Use UTC by Anonymous Coward · 2016-02-22 08:56 · Score: 0

Set your server to UTC and don't worry about it.
Then again... by stoatwblr · 2016-02-23 14:04 · Score: 1

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? by RockDoctor · 2016-02-26 00:00 · Score: 1

Why would you be doing a compression operation OVER AN EXTERNAL NETWORK, rather than crunching the file locally, then transmitting the compressed data over the internet. Unless you're seriously of the opinion that you can get higher actual communication speeds over a shared line servicing hundreds or thousands of other customers (compared to cables in your own wiring loom). That's to say nothing about the latencies and delays that are inherent in the Tor system itself.

--
Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"