Securely downloading In-app purchases?

I successfully verify in-app purchases from the apple store, and then my app downloads the content from my server. The problem is if a user sniffs the outgoing url request, they will have access to all my content. I've scoured the internet and I've gathered that security is not a simple proble开发者_StackOverflowm to solve, and if you are really serious you should employ multiple layers. I'm just one developer and weighing the risks/effort, I'd really just like to make it more difficult to steal my content than simply looking at outgoing url requests.

Is there anything I can do? Just verifying the receipt isn't enough, I'd like to have my server allow only iPhones/iPads to download from certain folders, or provide custom urls to folders hidden otherwise.

EDIT: in the meantime, I've found this question to be relevant, but it doesn't directly answer my question. In fact, the only solution offered isn't a solution for me, since I want my content to be available on all devices owned by the same user. I just don't want somebody to be able to type the URL they found into a browser and download all my content.

---

Can you switch to TLS or SSL HTTP sessions? That'd reduce the chances of sniffing the URLs.

If you generate extremely complicated per-user URLs then you could have some level of faith that clients cannot simply guess URLs for content they have not purchased.

For example, instead of offering your new content via:

http://ns6string.example.org/app-content/spanish/verbs/

offer it on a different URL:

http://ns6string.example.org/app-content/sarnold/
   646718ae5d25cac14775ca7074cf4808/b493881b4376a5162a38114d1bd2d88a

I generated those ridiculous URLs with:

$ echo "sarnold spanish" | md5sum
646718ae5d25cac14775ca7074cf4808  -
$ echo "sarnold verbs" | md5sum
b493881b4376a5162a38114d1bd2d88a  -

Each user could get their own piles of horrible URLs, and it'd take more than the average amount of effort to reverse it. (Of course, for this simple example, if I just bought the "spanish verbs pack", I might stand a good chance of guessing the URL format. Not much you can do about that, as no matter how complicated you make it, someone with debugger access or plenty of free time could probably figure out the URL obfuscation mechanism.)

Which is why I picked simple mechanisms: TLS and hashing ought to be fast enough to develop that you don't waste too much of your time working on protecting your content rather than writing new features or fixing those last few annoying bugs.

---

Not only could you verify the receipt, but you could obfuscate or encrypt the download using some portion of the receipt unique to the purchaser but that isn't a part of the URL.