I want to host copyrighted data on a Amazon S3 bucket (to have a larger bandwidth available than what my servers can handle) and provide access to these copyrighted data for a large numbers of authorized clients.
My problem is:
- i create signed expiring HTTPS URL for these resources on the server side
- these URL are sent to clients via a HTTPS connection
- when the client uses these URL to download the contents, the URL can be seen in clear for any man-in-the-middle
In details, the URL are created via a Ruby On Rails server using the fog gem.
The mobile clients I’m talking about are iOS devices.
The proxy I’ve used for my test is mitmproxy.
The URL I generated looked like this:
https://mybucket.s3.amazonaws.com/myFileKey?AWSAccessKeyId=AAA&Signature=BBB&Expires=CCC
I’m not a network or security expert but I had found resources stating nothing was going clear over HTTPS connections (for instance, cf. Are HTTPS headers encrypted?). Is it a misconfiguration of my test that led to this clear URL? Any tip on what could have gone wrong here? Is there a real chance I can prevent S3 URL to go clear over the network?
So firstly, when sending a request over SSL all parameters are encrypted. If you were to look at the traffic going through a normal proxy you wouldn’t be able to read them.
However, many proxies allow interception of SSL data by creating dummy certificates. This is exactly what mitmproxy does. You may well have enabled this and not realised it (although you would have had to install a client-side certificate to do this).
The bottom line is that your AWS URLs could be easily intercepted by somebody looking to reverse engineer your app, either through a proxy or by tapping into the binary itself. However, this isn’t a ‘bad thing’ per se: Amazon themselves know this happens, and that’s why they’re not sending the secret key directly in the URL itself, but using a signature.
I don’t think this is a huge problem for you: after all, you’re creating URLs that expire, so even if someone can get hold of them through a proxy they’ll only be able to access the URL for as long as it is valid. To access your resources post-expiry would require direct access to your secret key. Now, it actually turns out this isn’t impossible (since you’ve probably hard-coded it into your binary), but it’s difficult enough that most users won’t be bothering with it.
I’d encourage you to be realistic with your security and copyright prevention: when you’ve got client-side native code it’s not a matter of if it gets broken but when.