Wireshark network analysis : 1 : Chrome website access

I have previously used Telerik Fiddler Everywhere to capture / analyse traffic between my iPad and Denon amplifier.  It does an excellent job but is quite expensive to use regularly and a bit difficult to configure for occasional use.  Wireshark is the best-known network analysis software and I wanted to familiarise myself further with its use.

Wireshark runs on Windows and can only analyse traffic through the ethernet or wifi interfaces, that is to say traffic to or from the PC.  As a first example I decided to look at traffic to/from a Chrome session.

First Attempt : BBC

I picked www.bbc.co.uk as a frequently used web-site without advertisements.
To identify BBC related packets in wireshark I need its ip address, which can be obtained using the nslookup command.   Unfortunately the BBC web-site has a complicated front-end which is to be expected with a heavily used, high volume site and there are a number of possible IP addresses.

If I type www.bbc.co.uk into Chrome I am redirected to a signon screen.

Looking at wireshark I can see that a number of IP addresses are involved in the hand-shaking/retrieval of this first page.

Packet 3507 shows a DNS request to 8.8.8.8 (the Google DNS server).
Packet 3512 shows a request to www.bbc.co.uk port 80 (http) at 212.58.236.1
Packets 3513-3515 seem to show requests to port 443 (https).
Packets starting at time 19.769s (3507) through 19.86s (3544) appear to be part of this initial dialog.
It is much to complex for us to understand the way that the bbc is setup so I abandoned it.

Second Attempt : example.com

I decided to use example.com, which is a simple  and useful training / testing site for web development.  It has a single IP address.

Typing in the URL https://example.com still gives us quite a lot of packets.  Unfortunately the Protocol is TLSv1.3, so the packets are encrypted and it is not possible to work out what they contain. 

+

If I use the URL http://example.com traffic is not encrypted and I can look at the contents of http protocol packets.  This gives me the details of information being exchanged between Chrome and example.com.

As all internet pages need to use https, this approach isn't going to be very useful to me, but it is instructive to see some live internet traffic.

Third Attempt : local web page

I setup a simple web page test.html on my local raspberry pi web server so that I can get a more detailed view of traffic.  I use wireshark to capture http packets from the web server

This gives me a dialog I can understand.  Starting at packet 1736 Freedom contacts PI40 on port 80 (http). After receiving an acknowledgement Chrome does a GET request for the web page (packet 1740).  The response in packet 1742 comprises HTTP headers and the page.
We can see the raw data on the right of the page and the formatted equivalent on the left.

Conclusion

It is very useful to familiarise myself with Wireshark using simple examples.  It has also demonstrated to me that it isn't going to be possible to use wireshark to look at "commercial" traffic owing to the complexity of network environments and the univeral use of encrypted HTTPS traffic.  Decryption of HTTPS traffic may be possible using Fiddler Everywhere or by gaining some in-depth understanding of decryption.  However, for my purposes I need to restrict myself to local traffic without encryption.