As many people are probably doing right now, I've been investigating ways to incorporate the
However, what happens if someone wants to use their personal iPad at work and asks for iTunes to be installed on their desktop to accompany it. Although this hasn't been tested in court as far as I know, it is the opinion of many a General Counsel that U.S. corporate entities must own a license for any copyrighted media stored on its computers whether the user of that computer has a license for it or not. This is the main reason that we block MP3 download sites -including the iTunes store. Alternately, what if they are using their personal laptop and iPad at work (attached to our guest network, of course). We still want to block those sites on our guest network (this time for bandwidth reasons) but someone may have the need to update their iStuff.
The problem is that iTunes is required for updating the OS on iPads and iPhones, but that network traffic is identified by Websense the same as if the user were downloading Justin Bieber's latest musical masterpiece.
This raises an important question. How do we allow people to use iTunes to update their iPhones, iPads, and iTunes itself without granting access to the iTunes Store to download movies, music, or other media?
Of course, the first thing I did was contact Websense to see if they had already addressed this issue and had a solution. The answer is, "not exactly." Since this translates to "no" I decided to continue on my own.
Google searches turned up nothing useful. I even broke down and tried Yahoo and Bing "just in case."
So I did what any self-respecting geek does in this situation. I made sure I had plenty of caffeine within reach, fired up Wireshark and Fiddler web proxy, and started testing.
Since we are currently only using the Websense URL filtering product and not their more advanced Web Security Gateway that allows deep packet inspection and HTTPS traffic interception, this solution has to be entirely based on the URL that is being requested not a full packet analysis. Additionally, depending on whether the URL request is made before or after the SSL session has been established, Websense in standalone mode can sometimes only see the IP Address and not the full URL.
Because of this, I would be relying more on how Websense reports the URL's in its logs than what I would get through Wireshark or Fiddler but they're good for confirmation and clarification.
I intentionally started with an older version of iTunes on my test machine so I could capture an iTunes software update as part of the process. After updating iTunes, I went through the process of downloading podcasts, songs, apps, TV shows, and movies.
The first thing I noticed was that some of the URL requests were already categorized as "Information Technology;" specifically, any of the files served by EdgeSuite.net and the actual iTunes software download request.
Unfortunately, iTunes never gets to the download without checking the current version first and the version check URL requests are being classified as "MP3 and Audio Downloads" so we'll definitely have to recategorize these.
In order to decipher some of the URL requests (like that stupid bag.xml that keeps popping up throughout), I tried visiting the URL's in a browser but they either redirected to the normal iTunes web page or the returned data didn't quite match what I expected. For example, the bag.xml file appeared to be plain text not XML as the name would suggest.
Looking at the request header in Fiddler, I saw that the iTunes client has a specific User Agent string (I would have assumed it used a generic Safari/WebKit string).
itunes/10.1.1 (Windows; Microsoft Windows 7 Enterprise Edition (Build 7600)) AppleWebKit/533.19.4
No, that's too simple. They aren't just... OK, just to be sure I added the iTunes User Agent string to the User Agent Switcher add-on for Firefox and tried again. Sure enough; Apple is using the User Agent to determine whether to deliver the correct data for those requests. So now I can see that bag.xml includes a signature hash. I have to assume this is related to DRM and that it's necessary for the software update since it occurs any time iTunes makes a download request as opposed to a simple browsing request.
I determined that there are three URL's necessary for updating the iTunes software that will need to be recategorized to an approved category.
First, you're not imagining anything. There is indeed a trailing dot after the top-level domain in the first and third URL's.
I'm convinced it's because Apple hates me.
The first URL appears not to change in my limited tests so we can be pretty specific here.
The machineID parameter in the query string of the second URL will change based on the -wait for it- machine. The machineID is a 16 character hexadecimal value but has been redacted here.
Finally, the query string in the third URL changes fairly dramatically.
I wanted to keep the number of additional rules to a minimum and these URL's have enough in common to write a single Regular Expression to cover all three. I also wanted to leave enough leeway in the rule to allow for changes to the subdomain.
This is the rule I put in place.
Before you chastise me, dear regex gurus. Websense's regular expressions engine appears to have a few idiosyncrasies that prevented me from making this more graceful (I'm planning on doing an analysis of their regex engine some day so stay tuned). Websense also automatically assumes the protocol prefix is appended so it doesn't make any difference for me to add in a requirement for it in the rule.
This rule has been tested and enables both iTunes updates and iOS updates without allowing access to the iTunes Store. If you're using Websense, the user will get a block page in the content pane of iTunes, but the rest will function properly.
Here's what the user sees and although it may cause some confusion with the block page being presented, proper communication to the users should prevent too many support calls.
|iTunes Software Update|
|iPhone iOS Update Downloading|
|Device Management Functions Normally|