While inspecting the iTMS protocol with sniffers and PyMusique, I have found what appear to be three security issues: 1) Although signup/user info, authorization, shopping cart and purchase transactions are all sent via SSL, other transactions (such as searches and album info requests) are not. These requests are in fact sent in the clear, and the responses are either encrypted with a static key (prior to 4.7) or a key that's included in the HTTP headers (with 4.7). This means that anyone can sniff this information. 2) Worse, it means that a man in the middle can alter the response. It may not be obvious why this is bad, so I'll explain. Search results and viewAlbum responses include a field called "buyParams" which contains the ID of the item to purchase. This information is never displayed to the user; nor would they know what it means. Changing it means that the user will in fact purchase the wrong item. (Note that it has to be an item with the same price*.) If you have the shopping cart enabled, or you wait for your purchased track to download, you will probably notice immediately that you've been screwed, but in the latter case the purchase has already happened. 3) There is a specific transaction, sent via SSL, that informs the store that you've finished downloading a track, so it can be removed from your pending song list. This is what prevents you from downloading a track multiple times. If you can blackhole this transaction somehow, items will remain in your pending song list forever, allowing you even to download them to multiple machines. I presume it is implemented this way so that the client can automatically retry downloads as many times as necessary. As such, it might be hard to "fix" this without making the protocol flaky. * The price is displayed to the user (of course), and is echoed back to the server, over SSL, during the purchase process. If they do not match, the server returns an error asking you to "try again later". This is most likely to make it impossible for a user to get screwed by buying something like a "free" track while its price is being updated. (This is a good idea.) In this attack scenario, you'd want to substitute something with the same price, or else you'd have to change the price field and the user would probably notice.
