Things I'd do if I ever have time

Wish list

Please help a man further his career by donating expensive hardware. Cash works too.



Awakening the iPad (for the first time)

Published: 05/22/2010

Reference trace files:

ipad_initial_registration_filtered_by_mac_and_dns.cap
ipad_checking_for_update_filtered.cap
ipad_first-wi-fi_connect_peap_filtered.cap

Last month when I bought an iPad, I decided that the first thing I was going to do after opening the box (and before turning it on) would be to prep my network equipment for traffic capture. It's nice to imagine that Apple is a model citizen and its products would never leak personal information to the mothership, and if the iPad did (at least over non-secured channels) someone would eventually find out. But really, what is it doing when it connects to the network for the first time? That's what we're here to find out...

I have a MacBook that I occasionally use so I fired it up on the network, let it do its thing while it booted, and then started the sniffer on another machine after it quieted down so when I did initialize and register the iPad, the iTunes traffic would most likely reflect iPad-related activity.


iTunes registration

This first capture was performed on a SPAN port on the switch which mirrors the port that the network router's internal interface is connected to. Keep in mind that my access point and router are completely separate devices. In the trace I filtered out everything but the MacBook's MAC address and the DNS traffic (because I run an internal DNS server, name resolution requests for hosts outside my internal namespace would be made by it instead of the MacBook and iPad).

I plugged the iPad into the MacBook, read the EULA, and went through the iTunes / iPad setup. The MacBook's IP is 192.168.1.102 assigned by the local DHCP server. The Mac also uses the IPv6 address of fe80::219:e3ff:fe34:8179. The first thing we see are a couple of mDNS queries for _ptp._tcp.local using both IPv4 and IPv6. It tends to periodically do this. This is followed by a normal DNS query for ax.init.itunes.apple.com to the local DNS server at 192.168.1.140, which makes a forward query to Google's public DNS server at 8.8.8.8. This name is ultimately a CNAME which resolves to ax.init.itunes.apple.com.edgesuite.net, which itself resolves to a771.da1.akamai.net, which itself resolves to two IP address: 96.17.69.64 and 96.17.69.81.

The MacBook then makes an HTTP connection to the first IP:

   Show packet content

The web server responds with the XML content:

   Show packet content

The system then makes a DNS request for albert.apple.com which resolves to 17.149.240.65. An SSL connection setup is performed (TLS_RSA_WITH_RC4_128_MD5 is chosen as the cipher suite) and the server certificate details are visible in packet 38. According to the VeriSign certificate, albert.apple.com is apparently managed by Apple's iTMS Engineering group.

iTunes does the right thing and verifies that the issued certificate hasn't been added onto a certificate revocation list by doing a couple of OCSP checks against EVIntl-ocsp.verisign.com / ocsp.verisign.net / 199.7.59.72 and EVSecure-ocsp.verisign.com / ocsp.verisign.net / 199.7.48.72. Once the OCSP responses of "successful" is returned, there's a brief exchange within the SSL stream. I don't know what was uploaded to Apple, but something went to them based on the outbound packet sizes.

Almost two minutes into the capture at packet 154, the machine makes another DNS request for ax.init.itunes.apple.com (the DNS TTL is 2 seconds this time around while it was 20 seconds before) and then does another HTTP GET for /bag.xml?ix=3:

   Show packet content

It's pretty much the exact same request as before, except for the value in the X-Apple-Validation field. The results from the server:

   Show packet content

The machine now makes a DNS request for buy.itunes.apple.com which eventually resolves to 17.250.237.3. So while it looks like Apple's purchasing system should already know that I purchased an iPad at their store earlier in the day, iTunes needs to re-state this fact to Apple's servers again. Thanks. In any case, iTunes negotiates an SSL connection to this new server. Interestingly, the server uses a wildcard certificate (CommonName=*.itunes.apple.com). Presumably this is because there are a ton of iTunes servers to handle the constant load of media that music fans are buying! buying! buying! like its a stock market.

At packet 206, another DNS request is made for p17-buy.itunes.apple.com followed by more mysterious SSL traffic.

At packet 246, the machine looks for ax.itunes.apple.com, a slightly-differently named server from our first example. It then makes an HTTP request:

   Show packet content

The server response:

   Show packet content

and proceeds to pull more content down via both HTTP and HTTPS. I presume all this has to do with content that iTunes' application window displays to the end user. I'm not really an iTunes user so you'll have to excuse my ignorance. Eventually, we see an HTTP request for what appears to be something related to device registration:

   Show packet content

We see a few more similar transactions down the line. Lots more cleartext HTTP and SSL-wrapped exchanges follow.

At packet 1094 a DNS request is made for safebrowsing.clients.google.com. Hmm, an Apple device looking for a Google resource? What could this be? iTunes does an HTTP POST:

   Show packet content

This kicks off a download of something from safebrowsing-cache.google.com. I'd guess this is an updated list of phishing sites. I was too busy enjoying the new shiny-shiny when I initially did the capture.

Let's switch over to the second trace file where I look for any iPad firmware updates. We can see in packet 4 that the machine looks for http://itunes.apple.com/version?machineID=48273a0dc872d086 (which gets redirected to http://ax.itunes.apple.com/check/version, which in turn redirects to http://ax.itunes.apple.com/WebObjects/MZStore.woa/wa/com.apple.jingle.appserver.client.MZITunesClientCheck/version in packet 16). This results with an interesting (warning: and relatively lengthy) response from the server. I didn't bother formatting the horizontal output here:

   More Information