Understanding Network Communication and HTTP Packet Visibility in Wireshark

Intro: Why Can We See Some Sites and Not Others?

In our digital world, seeing what’s happening on the internet can be tricky. While tools like Wireshark let us peek at HTTP traffic on devices like Macs, we can’t always see every site. This makes us wonder, why are some sites visible and others not?

The digital landscape has evolved significantly, emphasizing the paramount importance of data security and privacy. This evolution has led to an increasing number of websites transitioning from HTTP to HTTPS, a move designed to bolster the integrity and confidentiality of data in transit. Below, we delve into the intricacies of HTTP and HTTPS, shedding light on their critical differences and the imperative shift towards a more secure web.

Understanding HTTP Vs. HTTPS

HTTP (Hypertext Transfer Protocol):

• Foundation of Data Exchange: HTTP stands as the cornerstone protocol that facilitates the exchange of information between web browsers and servers. It orchestrates the basic structure of how data is transmitted across the web.
• Inherent Security Vulnerabilities: The fundamental flaw of HTTP lies in its plain-text data transmission, lacking any form of encryption. This exposes data to interception and alteration by malicious entities, making it a less secure option for transmitting sensitive information.

HTTPS (Hypertext Transfer Protocol Secure):

• Enhanced Security with Encryption: HTTPS extends HTTP by integrating SSL/TLS encryption, thereby creating a secure channel over an insecure network. This ensures that data transmitted remains encrypted and incomprehensible to unauthorized interceptors.
• Mitigating Risks of Data Breaches: The inclusion of SSL/TLS encryption effectively neutralizes the threat of data breaches and eavesdropping. By authenticating the involved parties and encrypting the data, HTTPS preserves the confidentiality and integrity of the information exchanged.

Websites employing HTTPS protect their data rigorously, making unauthorized access exceedingly challenging. Tools like Wireshark, which are capable of monitoring and analyzing network traffic, encounter difficulties in directly viewing HTTP requests of sites secured with HTTPS. To inspect encrypted traffic, one must resort to filtering for “tls” or “ssl”. However, this approach does not unveil the encrypted packet contents, preserving the privacy of the data.

The inability of Wireshark to display requests from certain websites underscores the effectiveness of HTTPS encryption. The automatic redirection from HTTP to HTTPS, implemented by many sites, serves as a proactive measure to safeguard data against unauthorized access and cyber threats.

For example, we can compare how the Ark browser and Chrome handle a specific website. If you type http://gaia.cs.umass.edu/wireshark-labs/INTRO-wireshark-file1.html into the Ark browser, it automatically changes to HTTPS.

The Ark browser will redirect http://gaia.cs.umass.edu/wireshark-labs/INTRO-wireshark-file1.html to HTTPS, but Chrome doesn’t redirect it and shows a “not secure” warning instead.

So, Can We Decrypt to See the Data?

Yes, you can decrypt TLS and HTTPS traffic, but you need certain things, like a private or session key. With these keys, you can use Wireshark to decrypt the encrypted traffic. This only works if you’re the server admin or have the right permissions to access these keys.

Here’s how to decrypt TLS/HTTPS traffic in Wireshark:

• Using a Private Key:

You can decrypt the traffic with the server’s private key.

However, this only works in some cases, and newer TLS versions use Perfect Forward Secrecy (PFS), making it harder to decrypt this way.

• Using Session Key Logging:

You can log the TLS session keys from a web browser and use them for decryption.

Most modern browsers support this.

You need to set the SSLKEYLOGFILE environment variable and tell Wireshark where to find the file.

This lets Wireshark use the keys to decrypt the TLS traffic.

If you don’t have the session keys, the browser won’t show you the encrypted data. Nowadays, encryption with TLS or TCP keeps the data hidden.

Because, packet you expected is encrypted with TLS

Decrypting TLS Packets with Session Key Logging

Setting Up SSLKEYLOGFILE: Open a terminal and type the command to set the SSLKEYLOGFILE environment variable. This creates a tls_keys.log file on your desktop, where the session keys are saved. You can change the file's location and name if needed.

export SSLKEYLOGFILE=~/Desktop/tls_keys.log

Launching Chrome: In the same terminal, start Chrome. This will make Chrome save the TLS session keys to the tls_keys.log file.

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome

Capturing Encrypted Traffic in Wireshark: Start capturing in Wireshark, then visit a website to generate HTTPS traffic.

Specifying the Session Key File in Wireshark: Go to Edit > Preferences, select Protocols > TLS, and choose your tls_keys.log file. Now, Wireshark can decrypt the TLS traffic. Just filter for tls and you’ll see the decrypted HTTPS traffic.

Now, Wireshark can decrypt TLS traffic. Once you put tls in the filter and apply it, you can see the decrypted HTTPS traffic.

Note: Since we’re using Chrome’s session keys, make sure to start Wireshark before Chrome to capture and decrypt the traffic successfully.