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

It looks like I was given information for the iPhone, iPod, as well as the iPad. Yeah, sure, I'll take it all, thanks.


iPad does Wi-Fi / 802.1x / Protected EAP

So now that my iPad was officially registered in a manner approved by Apple, I was now able to actually do something useful with it. Since there's no Ethernet port on it anywhere, I started configuring the device for Wi-Fi. I was informed that this thing supports 802.1x, and considering I run PEAP at home via Active Directory and IAS, I was curious as to how I was going to get the root CA's certificate transferred onto the device in order to trust the AAA server certificate.

The third trace illustrates the very first time the iPad connected to a network (aside from QA tests done at the factory). The 802.11 beacons, probe requests and probe responses are filtered out here for the sake of trace output brevity. There's nothing necessarily out of the ordinary here, but this simply demonstrates that if you run PEAP you should be able to associate and authenticate the iPad onto the network.

Per the norm, the iPad does an 802.11 Authentication request at packet 1. The access point (a Cisco 1230) replies with an 802.11 Authentication response. The iPad supplicant then sends an 802.11 Association request and the AP answers with an 802.11 Association response with Status code of "successful." Great, now we get onto the good stuff...

The AP sends out an EAP Identity request in packet 5 and starts the whole 802.1x process. Its identity value is referenced with the SSID (who-disb) as well as its NAS identifier, which in this case is the AP device hostname (ufp-ap01). In packet 7 the iPad supplicant comes with an EAP Identity response. Somewhere along the line, the iPad had prompted me for my username on the screen, although probably not reflected within this trace itself due to the number of milliseconds between each packet shown and how slow I type on the iPad's virtual keyboard. Once entered, this value is sent in the response as the outer identity. Although this identifier could really be anything, the actual username that is sent in this example is "docrice" (the one I typed in).

At packet 8, the AP signals the start for the PEAP authentication sequence. In the next packet, the iPad sends a Client Hello to start the SSL / TLS negotiation with a random value and a list of supported cipher suites. On packet 17, we see the server certificate being sent from the RADIUS server and relayed through the AP (the few packets previous to it are the various fragments which make up the initial RADIUS server response). This Server Hello response shows that TLS_RSA_WITH_RC4_128_MD5 was the chosen cipher suite as well as the Star Trek-themed certificate data.

After a few more packets where the iPad apparently decides to trust the root CA which issued the RADIUS / AAA server certificate and finishes the SSL / TLS negotiation, at packet 29 the AP confirms that the EAP transaction setup was a success via EAP code 3. The WPA four-way handshake begins. Only three packets of the four-way handshake are shown here, probably due to radio reception and / or packet loss on the capture interface.

Everything afterwards in the trace is just 802.11 control frames (and eventually encrypted traffic after the trace ends) as expected. I've truncated the network capture to just the first 100 packets starting with the 802.11 Authentication request. The entire association / 802.1x authentication sequence took about 3.4 seconds.


More to come later

This article just covers the first few moments of the iPad coming to life from the factory. In the future, I'll look at what happens when I connect to and buy something from the App Store or have one of the installed apps determine my general physical location to display something geographically-relevant (like nearby restaurants cooking something I'm hungry for).


Go back to the main articles list.