HTTP - viewing HTTP messages in Wireshark
When attempting to capture HTTP messages such as GET or POST on Wireshark, using modern web browsers, you may find that you see no captured HTTP packets.
For example, you may start capturing packets and then go to www.cisco.com using the latest Chrome or Edge browsers. You may then use the
http.host=="cisco.com" filter to see all HTTP packets containing this string. This should show you all HTTP packets that contain the "cisco.com" string. However, you will not find any packets using HTTP, let alone any GET packets.
Some additional filtering options you can use include
tcp.port=443 for viewing HTTPS packets. Or you can specify only the destination port using
tcp.dstport==443 which will show only those packets traveling from the client to the web server.
Newer browsers don’t actually use a plain HTTP GET statement to receive web data. Using Wireshark, you can search for any instance of “cisco.com” as a string of text in any location within any packet, and you will find an entry in a packet that is using the TLSv1.2 protocol. The packet you will find will be a client hello as shown below:
This means that the browser is establishing a TLS session (sometimes incorrectly referred to as an SSL session - SSL is the predecessor of TLS) with the web server. It is within that TLS session that the HTTP GET request is sent, but this is encrypted, so Wireshark** cannot see it**. If you know the TLS secrets being used, you can use Wireshark's TLS dissector to decrypt and view the contents of such packets.
Alternatively, you can use an older browser such as Internet Explorer (IE). In the following example, using IE version 20H2 (OS Build 19042.1348) you will be able to see the HTTP GET messages as shown below. he lesson:
Notice in the above capture that you can’t actually see the “cisco.com" string in the HTTP portion of the packet. That’s because even this version of IE is using HTTPS, which is secure. So it is encrypted. However, Wireshark is able to decrypt and detect this text within the GET request, and that is why it can show it here.