Google is not my friend, I've been researching this one for a while and all I'm doing is chasing my tail.

I'm trying to add even more entropy to my fingerprint.

I'm not talking about cookie injection / capture / spoofing.

I'm trying to figure out a way to feed false info to a cookie that I allow to be set for sign in purposes. So that when it polls my system everything returned is false, including my IP address.

Any ideas?

Why would you store the IP address in a cookie*? Other than that I think you are just talking about editing cookie files in place? You can just open the file and edit it though the format may be difficult or impossible to track down.
Are't there cookie specifications for the various web platforms used nowadays, or is that the question?
Or do you mean your User Agent String also?

This kind of thing always intrigues me so if nothing else I'll likely google it myself at some point.

*There is no way to hide your gateway IP address and still receive packets, after all.

I know that "cookie" is a very generic term. I am referring mainly to http cookies.

The spec allows for IP address polling.

The NSA has used cookies in Tor attacks.

I know better than to allow any cookies when I'm on Tor and I have that under control. I'm speaking specifically of feeding false info to intentionally allowed http(s) session cookies in non-Tor sessions; mainly to futz the alogs as much as possible.

I am currently redesigning my privacy strategy.

I have multiple specific use VMs. I am not in my web-surfer right now. Instead I am in a wide open media VM. It is used for all streaming and anything that needs to be signed in to. It is all being cross-site tracked by the alogs through the cookies.

Over in the web surfer all cookies are blocked by default, as are all ads and scripts . Which allows me to read widely w/o adding to the advertiser's profiles and makes tracking me much harder b/c it would have to be at a top level sweep like XKeyscore as opposed to site to site profile persistence.

This combined w/ IP obfuscation through using commercial VPN service and User-Agent-String obfuscation through Secret Agent (random UAS rotation of the more than 1500 I inputted in to it) makes tracking me exceptionally difficult b/c I'm not allowing cross site profiles to be built, all my traffic is exiting a heavily trafficked VPN node and *every* request (even within pages) is fed a different UAS.

However, that does not solve the problem of being tracked by the few services I allow; for example Pandora. I run it in the open media machine while I read in the secure web browser, so no worries there. But, I am logged in here, on Pandora at the same time on the same browser and researching and linking; all of which can be tracked cross site to at least some extent b/c I am allowing the sites to establish session cookies to avail myself of services.

And, as I understand it, even if I run this traffic through a VPN the cookie protocol initiates a transactional request that since it is polling my IP address from my end will pull my *real* address. (Although one thing I'm not clear on is how "deep" that poling reaches outward. I.E. I'm on a LAN, so will that poling return 10.10.x.x or will it reach past my local gateway and pull my exterior IP assigned by my ISP? Which is part of what I want to prevent.)

-- EDIT-- Testing has shown me that it *IS* able to poll my real WAN IP assigned by my ISP--End edit.

So, what I want to do is figure out a way to feed false info to the cookies to futz the trackers.

The only tools that I have found so far to edit cookies in place in human readable format are either or both:
1) Paid and expensive
2) Lets you edit the cookie *after* it has been set

#2 defeats the purpose, at that point I'm already in the logs; even if I change the info after. And if anything, changing info after the fact would make me even more trackable b/c the top level sweep would be able to see in the logs that in between requests my session jumped from LA to Moscow.

I want to "feed" false info to the cookie during the actual initial transaction. And I was just using IP addresses as an example. The cookie protocol allows for polling of all kinds of "finger-printing" info; screen res, fonts and ton of other stuff. (Check out browserspy.dk .) And, anything that you ever put in to a form can be stored in cookies indefinitely if you're not taking security precautions: Address, SS# (or whatever you guys use over there), DOB, CC#, Phone#, etc. A veritable cornucopia for XSS attacks.

Yes

No

Trivial to spoof, see above.

Technically true, but not real world / use case true. You can chain things so that the last link in the chain does not know who you are. Of course the next to last link in the chain will always be able to see you. The trick is to make the chain long enough and a major PITA to track back through from the end back to the beginning! (Although that's not what I'm really talking about here.)

I *think* I might be making some minimal headway w/ greasemonkey scripts, but that area of research is still in its initial stage.

Kindly correct me if I am being ignorant here , but :

1. Doesnt the site's server place the cookie on your system "after" you have established a "valid tcp connection" to the site?

2. The way I see it is , you want to be more anonymous by feeding false information in a cookie that was created by a server side mechanism , during the time of its creation ? so that you are less trackable ?

Is this correct ?

Correct, the cookie is not part of the TCP/IP 3 way handshake.

Explanation of the Three-Way Handshake via TCP/IP

Setting the cookie occurs in the session layer of the OSI model and is independent of the network connection parameters.

The OSI Model's Seven Layers Defined and Functions Explained

The "cookie" is basically just an http header requesting information about the local system which directs the system to create a text file with the requested info in it so that the server can identify the client across requests.

HTTP cookies explained

The problem that I have with this is that the cookie spec allows the server to "ask" some rather invasive "questions" about me. And much of that info is stuff that the remote system usually doesn't actually need for the desired transaction to function correctly.

Yes and no.

The server does not reach out and "plant" a cookie on my system. Instead it asks me to basically answer a bunch of questions about myself and dump the answers in to a text file that gets sent back to it w/ every request.

The problem that I have w/ this is that the process is not static. The cookie can be, and usually is, polled for updates with every request. In this way cross site profile linking can occur b/c the constantly updated cookie has the ability to ask my system to inform it of any other open http request; even ones that have no connection to the 1st site in question. For example, in the example above, Pandora knows that I currently have pages open there, here and at MS. That is none of Pandora's beez wax!

So, I want to spoof the answers in such a way that the transaction still not only functions, but that I am also not as identifiable or as "trackable". I.E: send back non-true but functional info about "who / where I am" and cut off all info about what else I'm looking at.

I am not finding easy answers (or hard answers for that matter) and believe that any solution will involve an increase in skill level. If there is a solution that won't simply just "break" the internet for me.

Have you considered the possibilith that the server that dropped the cookie will detect that it has been altered and drop a valid one to use in its place?

I don't know how likely that is, or even if it's possible, but the thought occurred to me that, if the server reads the cookie, the server can also recognize that it's not to spec, as it were.

As noted above: Servers do not "drop" cookies. They ask you to answer a bunch of questions about yourself. The answers *are* the cookie. In so far as I know trust of the answers is implicit and there are no verification parameters. In other words, so long as as the answer is valid it is true.

The trick here would be to make sure the answers stay "vaild"; for example, a random IP could not be truly random. It would have to be constrained by geo-location parameters so that the server does not try to serve me the text in a foreign language, nor is the IP in any of the reserved blocks, nor is it an impossible address.

In this instance the only "spec" is respecting format and serving "plausible" / consistent info as there is no built in verification procedure and all valid answers appear to be accepted at face value.

I *think* that it could be done with a greasemokey script. After all, scripting has to be allowed to run on pretty much any site any more where you expect any type of interactive transaction (streaming, email, posting, etc). But that level of scripting is currently well beyond my skill level.

1 members found this post helpful.

I am aware of the networking stuff behind the data exchange there.

Also I appreciate your efforts to anonymize yourself by cookie-handling-obfuscation (if I may put it that way ) , but I can only second frankbell here.

I believe you can fake the details at the max but not the IP.

The reason being if the IP is fake/made up, then communication will happen with the wrong IP in which case the cookie will be considered invalid.
In such case the server simply may put another new cookie.

To explain more, perhaps you should go through the following link : https://www.ietf.org/mail-archive/we.../msg01771.html

Also the RFC link for your topic at the following : https://www.ietf.org/rfc/rfc6347.txt

clearly states - When the second ClientHello is received, the server can verify that the Cookie is valid and that the client can receive packets at the
"given IP address".

and also states - If a server receives a ClientHello with an invalid cookie, it SHOULD treat it the same as a ClientHello with no cookie.


I hope you get my point.

1 members found this post helpful.

Thank you both, Steve_G and pengu_penguin.

This is what I love most about this place, besides the welcoming and helpful spirit. One learns stuff in the most unexpected corners of the discourse.

Actually, that is not how HTTP cookies work at all.

The server does indeed "drop", or set the cookie, and no other interrogation by the server takes place related to the cookie exchange. The server already has your identifying info, it is not sent in response to any server request.

Then, each time that you make a new HTTP request from that domain, any cookie previously set by that domain is sent along with the new request. The server may then refresh a cookie by simply sending it back with the header info, or it may set one or more new ones that way. It may also "remove" a cookie from your system by resetting it with an expiration time in the past (it is actually your user agent, or browser, that removes it).

A tracking cookie does not itself contain any information that you can spoof, instead they usually contain a checksummed unique identifer. You can send it an invalid identifier, but anyone really interested in tracking your traffic will detect that and simply refresh with a new one (aka, drop a new cookie). That unique identifier relates your request to other identifying information that they store (gathered from many sources) but the information itself is not accessible to you in any way.

Finally, if you expect to receive a response from the server you cannot spoof your IP address. IP is not part of a cookie response/request in any way - it is part of the TCP request header. If you fake it then the response will be sent off into nothingness but does not return to you, and the connection will not be established.

And that's where the scripting above my skill level comes in. I still think there is something to this and that it is plausible.

Remember, I'm talking about running behind a VPN, although if done right this could protect Tor users too.

I don't care if the next link in the chain can "see" me. I just don't want to be visible past that.

I'm just spit-balling now. I *think* you'd have to take a "step back" from the cookie itself and figure out how to write a script that did something like ran a traceroute and then spoofed the directly host polled header response to any point beyond the VPN / Tor node / I2P node / Freenet node. Probably by detecting the IP address of the node itself and reporting that as the local WAN/ISP IP. That way you're not sending stuff down a black hole. The server would still be sending it to the node; which would have the correct records to forward it to you.

As long as you weren't "lying" to the node the packet *should* still reach you?

It wouldn't be perfect, if someone dug through the logs of the node they could still find you. But at least a simple session cookie couldn't straight up bust IP obfuscation.

But now we're so far past my skill level that I wouldn't even know where to start.

I'm not referring to the underlying network parameters nor session identifier tokens. I'm *only* referring to the local host http header polling responses that can be stored in a cookie, or pulled directly.

That's why as I get deeper in to this I think you'd have to figure out a way to spoof the headers themselves directly. Then any values (IP, screen res, fonts, yadda yadd) in the cookie would(?) match the spoofed header.

But how would you *only spoof the header past the node* with responses from a falsely generated local polling?

Sorry, but I have not been able to understand the mechanism you are describing.

Spoofing "only past [some] node" would imply a rewriting proxy on the node I think, but you seem to want to do the spoofing locally as opposed to doing it on a proxy...?

And you seem to be describing direct http polling of your "local host" (browser?) by the remote server from a header... but I know of no such mechanism.

You may mean javascript polling of system capabilities...? But why would you enable javascript when trying to run anonymously...?

I'll try to parse it again after some needed sleep!

I can't help wondering whether you really know what you're doing and why?
If you're logging onto a site then the details you give them in order to log on are the same so they can track you through them no matter which IP, OS and the like you use. For example a government who doesn't like you could see which TOR exit nodes you use if you log on to this site using TOR.
In order to use the internet you need to give your gateway IP address or you can't get anything, as I mentioned.
So, I fail to understand what it is you think you can acheive by simply modifying cookies for site you have already given all your personal information to?
For what it's worth I only allow cookies for sites I want to use (about 5) and ms PCs are still unique for advertisers:
https://panopticlick.eff.org/

Some times talking to you two is like pulling teeth. And save the snarky 273, I'm not a moron and I do know what I'm talking about. You just aren't getting it.

I am talking about a very specific use case here. Think of it as I want to have my cake and eat it too.

I'm not talking about "normal" locked down purely anonymous, not fully functional, web surfing with all scripting off, all cookies rejected, all UAS's spoofed, redirectors off in the browser, the referrer header off, about:config locked down, from behind a VPN / non-transparent proxy / Tor / any forwarding node that does not use X-Forwarded headers. I have a web surfer VM that does my version of that for certain uses. I also have tails in a VM w/ no hard drive in it and on a booted / live DVD for other uses.

I'm not talking about that. I'm talking about having my cake and eating too.

(And the web site won't know anything about me if I'm signing up for the first time ever *after* I've "baked the cake".)

And yes, astrogeek, in this use case scripts would have to be allowed to run.

"Cookie" is a very generic term. There are E-tags, LSOs, session tokens, evercookies, nevercookies, supercookies, tracking cookies, 1st party / 3rd party cookies and I'm sure I missed at least 1 or 2.

In the formation of the cookie a remote server can, and often does, poll the local host for system information. Much of this information is gleaned from the local http header and incorporated in to the cookies. This often includes your *actual* IP address from your local http header, even if you are behind an IP obfuscation node as listed above that would normally report your address as something dif if the remote host was only reading the last header in the chain instead of initiating a poll of the local host.

In a nut shell, what I am trying to do is figure out a way to spoof that local poll w/o breaking routing.

I don't even know if that can be done.

My current "privacy" (not *really*) solution is to isolate all such non-private activity to a dedicated "wide open" media usage VM that has strict cookie and scripting controls in place. However, to use interactive services I cannot completely shut down all information exchange and must allow at least some 1st party session tokens and some scripts. And some times sites are even built so that they will not function in an interactive / non-static mode w/o 3rd party scripts and cookies being allowed.

In an *ideal world* I would be able to cook up some kind of a "stateless" connection that would allow me to log in to such a service and still retain my anonymity.

The only way I can imagine that could be done would be with counter-scripting; since scripts have to be allowed any way to use interactive services. We might as well use them for something beneficial.

The script would have to be able to do something that is completely beyond my current skill level: "lie" to the remote server about the local host, including the real IP address, w/o breaking routing. I was spit-balling ideas on how to achieve that. But I honestly don't even know where you would begin.

If either of you have any ideas for how to do that they would be greatly appreciated.