Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#1579 closed enhancement (duplicate)

ETag and If-None-Match header can link multiple requests to the same page

Reported by: bee Owned by: mikeperry
Priority: Low Milestone:
Component: Applications/Torbutton Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Yeah!!!!!!!! I found a way to track what users are doing!!! It works against all tor bundles (for windows, linux and even against my factorbee!!! with or without polipo and torbutton!!!!) I wrote a demo too!!!!!!!!!!!!!!!

http://honeybeenet.altervista.org/fun/tracker/ (open it with tor!!!)

Great catch, this one!!!!

bye!!!!!!!!!!!!!
~bee!!!!!!

Child Tickets

Change History (10)

comment:1 Changed 9 years ago by nickm

Priority: blockernormal

So, are you going to say what the attack is?

comment:2 Changed 9 years ago by bee

Priority: normalblocker

Not to you!!!!!!! you dont like me but i don't like you too!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

~bee!!!!!!!!!

comment:3 Changed 9 years ago by nickm

Status: newassigned
Summary: Tracking usersETag and If-None-Match header can link multiple requests to the same page

Okay, so here's the problem: When a web server attaches an ETag header, most browsers will use it in the "If-None-Match" headers for future requests for the same URL to avoid downloading the same entity twice. It looks like Torbutton doesn't currently stop this.

Thanks for the bug report and the demo, bee!!!!!!!!!!!! And thanks to the helpful people on #tor who helped reverse-engineer this deliberately unhelpful bug report, particularly vegard.

comment:4 Changed 9 years ago by nickm

Phobos reports that this is in the literature as http://kuza55.blogspot.com/2007/05/tracking-users-with-cache-data.html

comment:5 Changed 9 years ago by bee

Yeah!!!! It's a-thanks to me!!!! and you're welcome, nickm!!!!! Many people here are calling themselves `experts' but they couldn't have found this flaw in two hundreds of years!!! this is why it existed till now!!!!! Hahh!! wait, i'm flying too fast!!! actually it hasn't been patched yet!! lolol!!!!!!!!!!!!!

It's funny to know there is also a three years old article about this, and nobody of you read it before!!!!!!(neither i did it!!lol!!!!!!!!!) I ain't surprised phobos, the blogger, found it!!! very honey!! he's better than a thousand and one mikeperries!!!

Well, finally, as the bug report is in front of you, try to solve it!!!!!!!!! you could use the demo page (i had fun in writing it!!!!!!!) to test if your patch works!!!!! yeah!!! and have fun you too!!!!!!!!!

bye!!!!!!!!
~bee!!!!!

comment:6 Changed 9 years ago by mikeperry

Priority: blockerminor
Resolution: duplicate
Status: assignedclosed
Type: defectenhancement

Dear Bee,

You continue to demonstrate your unhelpful behaviour, illustrating and archiving for all the world to see why the Tor Project has decided that it is utterly impossible to collaborate with you.

We've explicitly stated numerous times that it is important to communicate your ideas effectively if you want people to take you seriously. Again, this has nothing to do with exclamation points, and has everything to do with treating people with respect, forming complete thoughts, and actually *explaining* what you're doing. So far, you've done nothing but incoherently insult our work from the very beginning, despite your "FactorBee" software using many components the Tor Project has produced. Your patches and ideas do not come with explanation, reasoning or comments, and instead are laced with insults and ego bravado.

You get one small point for finally successfully using our bugtracker (though obviously only to promote your own ego), but you lose several dozen points for not explaining your "exploit". If you had actually bothered to explain it, perhaps someone would have instantly told you that it has been addressed by TorButton for the past 3 years. See:

https://www.torproject.org/torbutton/design/#attacks
https://www.torproject.org/torbutton/design/#id2979312

and the first public demonstration of the cache exploit attack:
http://crypto.stanford.edu/sameorigin/safecachetest.html

Your attack is no different than setting a cookie as far as Torbutton is concerned. In fact, setting a cookie is actually more effective against most of our users, because most of our users probably actually keep their Tor cookies on disk in Torbutton's "cookie jar". However, Torbutton has no option to persist cache data beyond a quick toggle of the button.

Toggling the Torbutton quickly resets the visit count on your exploit page to 0. Try it.

At best, this issue is a dup of Ticket #523, where I mention that if we implement a "New Identity Button", we should provide the option to have it run on a timer, expiring cookies, cache, and other tracking info every few hours, if the browser is idle.

If you recall, I actually showed you this ticket before in a previous non-conversation...

You continue to be a net drain on the Tor Project and its limited resources, despite any useful code or ideas you might occasionally produce. It's really a shame, because you do occasionally produce some useful ideas. You just make dealing with you so difficult that it is not worth using your work directly.

Please fix yourself, or go away.

comment:7 Changed 9 years ago by mikeperry

As an aside, if a user wants to block cookies for Tor usage, they can also completely defeat this attack by selecting the Torbutton->Security Settings->Cache->"Block Disk and Memory Cache during Tor" radiobutton.

comment:8 Changed 9 years ago by bee

You compare this bug with setting a cookie!!! Well, it's right!!! or almost!!!!
For sure, you can toggle the button or change the "Block Disk and Memory Cache during Tor" radiobutton!!! And, it's also true that you may as well inject one cookie and hope for it to being saved into the cookies jar!!!!!!!!! rather than using the ETags!!!!
But, you may also use an http proxy to strip HTTP headers!!! it's possible to stay safe from cookies and others http headers, in plenty of ways!!!! they're just not always common or easy!!!!
TorProject's Browser Bundles are unsafe by definition!!!
Cookies are enabled!! Javascripts are enabled, though with limitations, and of course also the "Block Disk and Memory Cache during Tor" option is off!!!! Only plugins are disabled!!!!

So, the ETag header is something that goes through TorButton as well!!!!!! And, it's much less noticeable than cookies!!!!!
Yeah, i know that "about:cache" could work, but there isn't a tool like the internal cookie manager of FireFox made to quickly look at the stored etags!!!!!!

Surely, it's possible to defeat this attack, in a way which is turned off and absolutely disabled by default!!!!!!! (which make sense if you even keep cookies enabled!!!!!!!! which is what you can expect from TorProject's standards!!!!!)

bye!!!!!!!!
~bee!!!!!!

comment:9 Changed 9 years ago by mikeperry

Disabling everything by default is not the solution. It makes the web unusable. The right solution is to allow these mechanisms (cookies, cache, javascript, CSS) to function, but to limit what they can obtain and store.

This is why the correct solution is the existing ticket #523 (which would handle the general case of cache, cookies, open tabs, and everything else), not shipping an unusable TBB. Our TBB package is targeted at users who need something that works out of the box with no configuration.

Doing things right is hard, and takes time, resources, and patience.

comment:10 Changed 9 years ago by bee

That's untrue!!!!!! So, what you're shipping now, is an "out of the box" vulnerable product!!!!! yeah, three years and you didn't found yet a working solution for this flaw!!!!!!!!!!!!!!
As a matter of fact, the exploit page continues to work against TorButton!!!!!!!!!(the "out of the box TorButton"!!!)
Also, it's your way the way to defeat the flaw disabling all the caches mechanisms!!!!! It's effective, but it sounds strange to me too!!! although if you didn't found better ways, it's better than nothing!!!! Yet, you aren't using it either!!!!

Nevertheless, i've to say that in place of a TBB with all features active, to work "out of the box" together with all the possible imaginable flaws!!! i do prefer a TBB like factorbee!!! where many features are disabled and whenever you need them, you can switch on what you need, when and whether you need it!!!!!! "deny all, but allow this and that"!!!!!

In the meantime ETags or just cookies, can be used to keep a thread of what you're doing!!!! until you toggle the button or clear the caches!!!

~bee!!!!!!!

Note: See TracTickets for help on using tickets.