Hi; I'm wondering if it's feasible (and if so, how one might go about it), to implement a system whereby a game client can make a request for a certain bit of data that it doesn't have direct access to, to a server (which knows where to find it - for instance, in an Amazon S3 bucket), and have the server then have the data transferred/downloaded from that source to the client without the client knowing exactly where it came from?
The motivation for this is the use of an open source client and a closed source server, and not allowing someone with access to the client code to intercept somehow the source of the transfer. Easily, anyway - for example, by modifying the source to output the URL of the resource it's downloading - I understand that anyone determined could probably subvert it, I'm just curious if it can be made somewhat more difficult.
Is that possible?
Thanks.
Game Data Download Proxy
You could use libcurl on the client to make the http request to where ever your server is, but it will always be very obvious where the data is coming from.
This isn't a good security tactic though, not even in the least.
What do you hope to accomplish by hiding the location of where the data is coming from?
If you answer that question, we can probably help you come up with a more reasonable security solution - if you even need one (:
This isn't a good security tactic though, not even in the least.
What do you hope to accomplish by hiding the location of where the data is coming from?
If you answer that question, we can probably help you come up with a more reasonable security solution - if you even need one (:
Author
> What do you hope to accomplish by hiding the location of where the data is coming from?
You know, the more I think about it the less important it seems :)
It'll be purchased content, so the idea was that someone who got hold of such a URL couldn't publish it for anyone who wanted to download it for free. Yeah, someone could then just share the content they've downloaded but that uses up their traffic rather than mine.
I guess a more solid solution would be some sort of 'whitelist' system on the machine where the data is kept, that keeps a record of 'allowed clients' and only lets them access the data if they're in the list (perhaps by IP - yeah, I'm sure that can be forged, but the server could take an IP off the list once the purchaser has downloaded it/after a given timeout)... is such a system possible?
You know, the more I think about it the less important it seems :)
It'll be purchased content, so the idea was that someone who got hold of such a URL couldn't publish it for anyone who wanted to download it for free. Yeah, someone could then just share the content they've downloaded but that uses up their traffic rather than mine.
I guess a more solid solution would be some sort of 'whitelist' system on the machine where the data is kept, that keeps a record of 'allowed clients' and only lets them access the data if they're in the list (perhaps by IP - yeah, I'm sure that can be forged, but the server could take an IP off the list once the purchaser has downloaded it/after a given timeout)... is such a system possible?
Author
Thinking about it, I guess the ideal thing would be management of something akin to symbolic links by the server. I'm looking into S3 documentation wrt that, but if anyone has any tips they're most welcome.
EDIT:
Sorry, I may have found an equivalent solution to this myself. For anyone interested: the server can generate temporary S3 URLs using a feature they call 'query string authentication' which provide public access to a private resource but expire after a specified time period.
[Edited by - TropicalPenguin on October 21, 2010 9:34:08 PM]
EDIT:
Sorry, I may have found an equivalent solution to this myself. For anyone interested: the server can generate temporary S3 URLs using a feature they call 'query string authentication' which provide public access to a private resource but expire after a specified time period.
[Edited by - TropicalPenguin on October 21, 2010 9:34:08 PM]
You could have a simple challenge/response protocol with the server before allowing a download. A dedicated hacker could figure out what is going on but it would be enough to deter casual abuse.
Whitelisting IP addresses sounds like a recipe for disaster. It will probably be a nightmare to maintain, and it will punish legitimate users if it goes wrong. IP addresses can and will change, you cannot reliably identify a user by IP. In particular, due to NAT you might find multiple legitimate (and possibly illegitimate) clients sharing a single IP.
If each client executable had an embedded key then you could have an implicit whitelist based on cryptographic key signatures. You could then have a blacklist of revoked keys which, based on your logs or whatever, appear to be abusing the download system (which is evidence that a particular executable being pirated or shared). This isn't easy to implement though.
What kind of data is it?
Whitelisting IP addresses sounds like a recipe for disaster. It will probably be a nightmare to maintain, and it will punish legitimate users if it goes wrong. IP addresses can and will change, you cannot reliably identify a user by IP. In particular, due to NAT you might find multiple legitimate (and possibly illegitimate) clients sharing a single IP.
If each client executable had an embedded key then you could have an implicit whitelist based on cryptographic key signatures. You could then have a blacklist of revoked keys which, based on your logs or whatever, appear to be abusing the download system (which is evidence that a particular executable being pirated or shared). This isn't easy to implement though.
Quote:
For anyone interested: the server can generate temporary S3 URLs using a feature they call 'query string authentication' which provide public access to a private resource but expire after a specified time period.
What kind of data is it?
Quote:not allowing someone with access to the client code to intercept somehow the source of the transfer
What's the requirement that's driving this desire? The user already has the data, and can do whatever he wants with it.
If you want to somehow throttle bandwidth usage, have the delegating server issue a single-use token to the client, and have the "source" of the download data require a valid, unused single-use token when delivering the data.
But why wouldn't you just send the data through the server the user is already connected to?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
