Understanding Networks: Packet Analysis


Capture and analyze traffic on your home network while going about your usual network activities. Present your results in summary form, using graphical analysis where appropriate.

background traffic analysis

I used wireshark throughout the assignment in the ITP-sandbox network.

After a few basic experiments with querying a very basic webpage and looking at the sent/received packets, I went back to zero: I started measuring just traffic when all applications are off over the course of 5 minutes. Surprisingly there is still a lot of background network traffic happening, especially application data, without me actively engaging in any online activities.

OS X source traffic (my IP:

OS X destination traffic (my IP:

Ubuntu source traffic (my IP:

Ubuntu destination traffic (my IP:

I used two operating systems to compare the background traffic: OS X and Ubuntu. Ubuntu only shows one third of overall network traffic compared to OS X.

The latter one shows a lot of connections to IP addresses starting with 17 - these are registered to Apple in Cupertino. A more detailed view shows a variety of different activities that my OS X operating system is performing and sending data back and forth between Apple servers and my machine:

Screen Shot 2018-10-27 at 3.59.12 PM.png
Screen Shot 2018-10-27 at 4.43.15 PM.png
Screen Shot 2018-10-27 at 4.42.20 PM.png
Screen Shot 2018-10-27 at 4.37.04 PM.png

Some further research on the sent TCP-packets showed that those processes refer to Apple cloud services (as I am using iCloud to sync my photos, calendar etc.) or programs like iTunes.

On my Ubuntu machine, I do not use any cloud service that that is tied to the operating system, therefore 1/3 of background activities.

As I got interested in this “hidden” traffic I did some further research on the TLS - Layer and used wireshark to go through each step of the TLS -protocol:


Looking at the cipher change protocol specifically, I did further research on the encryption part (here the negotiated cypher-suite) of TLS - and finally understood Diffie-Hellman and RSA encryption. That was worth the extra hours … ! I have to confess that trying to sketch all components of RSA encryption still gives me headaches, compared to that Diffie-Hellman seems a bit more simple and elegant. To me it was not obvious to choose which one over the other, intuitively I would choose Diffie-Hellman over RSA. And I wondered why Apple is “downgrading” my (possible) SHA384 encryption to SHA 256 in the cipher suite negotiation in the protocol.

Screen Shot 2018-10-27 at 7.25.07 PM.png

After reading the Diffie-Hellman vs RSA post on stackexchange, I was a bit less confused: Non-ephemeral RSA encryption seems to be the industry standard for now as its generally faster to compute. Diffie-Hellman is more secure, but more difficult to compute.

I suspect Apple is using the lower encryption standard (RSA with SHA 256) due to the sheer volume of traffic on their servers.

usual daily network traffic analysis

For my usual daily network traffic analysis I had a couple of browser windows open, mail and terminal. In one of the browser windows I was running an online-radio station (nts.live). I captured data over the course of 5 minutes.

Here the output looking at the source-traffic (my IP:, running OS X):

Here the destination side of traffic:

Finding out on which data channel my online-radio station is running proofed to be difficult as the stream is hosted not under the website-ip address but on a different server. I suspected either one of the ip addresses below as they showed a continuously high traffic via TCP (initially I expected UDP but as the stream is https, TCP makes sense). Both pointed to amazon-servers.

Screen Shot 2018-10-29 at 11.30.57 PM.png

To find out which one might be the one hosting the stream, I just closed the tab running the online radio station. Here the results:


To my surprise both were muted now and didn’t appear on the traffic overview anymore. As the website is hosting two streams at the same time, I guess it might load both from different servers even when I would only be able to listen to one? My fellow classmate Beverly pointed me into the right direction: I should check the sent packets in Chrome directly - and here two streams are loaded at the same time! This is for sure eating into the bandwidth …

Screen Shot 2018-10-29 at 11.48.07 PM.png

Surprisingly the connection to the Apple servers was somehow quiet during multiple wireshark-captures while running Chrome and Mail. The server-IP starting with 17 (apple server range) does not appear in the traffic overview at all. Why this is the case, is not quite clear to me. Maybe background processes are only run while no other traffic is using the bandwidth? I can only guess at that point.

Now enough of packet sniffing, TCP, TLS and UDP - I learned a lot and got a lot more interested in encryption, which will be the topic of a future class in a few weeks. Awesome!