Wireshark is a very useful tool for network troubleshooting, but also for Blue (discover attacks) and Red (sniff secrets) security teams.

Nowadays most communication will be encrypted, which makes it much harder to eavesdrop on network traffic. Just as a quick note I wanted to show how easy it is to have Wireshark decrypt TLS traffic, as long as you have the private key of the target. There are two big ‘but‘s (pun intended):

1. A private key is exactly that – private. If you are not the owner of the key, you should not have it. Also not for troubleshooting.
2. If the server you are visiting is supporting and enforcing current encryption technology, a private key alone will not suffice to decrypt sessions.

Ok, so to be clear: Decrypting traffic with Wireshark does work – quite easily even – if you have the private key and the session keys for the connection you are interested in. For a private network you most likely can get these, but it’s good to know that we do not have to fear that hackers can easily eavesdrop on our online banking activity just by starting up Wireshark.

On the other hand we will see that even in encrypted traffic eavesdroppers will still be able to see where you were browsing to. We will therefore also see why DNS over HTTPS is a step into the right direction for more privacy.

Let’s have a look at the different scenarios.

Unencrypted traffic

As you might know, you can read along on unencrypted traffic using Wireshark and even extract media such as transferred images, audio, etc. If you are browsing to a website with “normal” HTTP (i.e. port 80), current browsers will let you know, that the connections “not secure”:

What is meant with “not secure”? Well, you can read everything what is transferred by using Wireshark:

So, that was easy. How about encrypted traffic?

Encrypted traffic – Still some things visible

Now it’s getting slightly tricker: If traffic is encrypted (port 443), we can still choose to read along the TCP stream observed by Wireshark, but it will look like gibberish:

As you can see in the screenshots above, “HTTP Stream” (layer 7) cannot be followed anymore, because it is encapsulated inside an encrypted tunnel. We can still follow the TCP stream (layer 4), but most of the transferred data will not be readable to us.

CDNs, connection coalescing & DoH – Extra privacy shield

Noted that in the TCP stream above, “fabian-voith.de” is still readable? This means that even in encrypted connections, a third person will still be able to see to which domain you are browsing.

Even worse, your DNS lookups for an initial page visit will go over the wire totally unencrypted! If an attacker wants to hurt you, this is one of the weakest spots: Tell the vitim that you as an attacker are a very trustworthy DNS server and we are off to a good start for a man in the middle attack. This is by the way the reason why in enterprise security monitoring you usually alert on occasions where systems are communicating over port 53 (DNS) with a target system that is not a known DNS server (and might therefore be an attacker). But I’m getting side-tracked here…

So, in the example above we can see that an attacker would be able to monitor the sites you are visiting just by watching encrypted traffic. What will not be visible is, to which subdomain you are browsing. Only the top-level domain (.de) and second-level domain (fabian-voith) will be visible, but not something like /subpage/moresubpages/verysecretwebsite.html.

The good news: Several arising technologies are going hand in hand, leading to a more secure and more private surfing experience. I’m talking about Content Delivery Networks (CDNs), HTTP/2 connection coalescing, and DNS over HTTPS (DoS).

Many complicated words, let’s put them together into an easy explanation: DNS over HTTPS is a technique that circumvents the problem I described a above: Your DNS requests which your system has to send whenever you are browsing to a website cannot be easily read and altered anymore, because they are encrypted.

HTTP/2 connection coalescing means that you can reuse existing connections. If you are visiting awesomewebsite.com and afterwards someothergreatsite.com and if both websites happen to be hosted on the same webserver, your browser can reuse the existing connection, without all the unnecessary overhead of establishing yet another one. RFC7540 explains, how this works:

An origin server might offer a certificate with multiple
“subjectAltName” attributes or names with wildcards, one of which is
valid for the authority in the URI. For example, a certificate with
a “subjectAltName” of “*.example.com” might permit the use of the
same connection for requests to URIs starting with
“https://a.example.com/” and “https://b.example.com/”.

This also means that in Wireshark we will not see another connection to another website – your visit to the second website is basically hidden in the reused encrypted connection.

What about the third point, content delivery networks? CDNs are providing their services to website owners who want their content to be delivered as fast as possible to the customers. If you are in Germany and want to visit a website that is hosted in the US, that traffic needs to travel quite a long way, making things pretty slow (and exposing the website to DDoS attacks). If the US website has a contract with a CDN, that whole internet presence might be mirrored on servers of the CDN. One of these might be sitting right next to you somewhere in Germany.

Guess what – many website owners are using these services for faster delivery, DDoS protection, WAF functionality and so on. With many websites hosted on one target, connection coalescing as described above becomes ever more efficient: more sites on one target = more sites for connection reusage. A man in the middle could see that you are connecting to a certian IP, but since this IP belongs to a CDN that hosts a huge number of different sites, it remains unclear for the attacker to which specific site you were browsing.

Mozilla has some very nice illustrations on how DNS over HTTPS and the added privacy shield thanks to connection coalescing work. Daniel Stenberg explains in detail how connection coalescing is being used by different browsers.

Reading encrypted traffic

Ok, but what if you do have the server’s private key? Well, then you could be able to decrypt that traffic. In Wireshark you would simply add the key and indicate which connection that key is good for:

Be careful when filling the “Protocol” field: You need to type “http” in lowercase. Writing it in capital letters (HTTP) will result in an error!

Also note that Wireshark will only be able to decrypt the traffic if you ensure that it can read the initial session handshake. If you did not capture it, you will need to reload the website. Voilà:

Session Resumption and Perfect Forward Secrecy

As I said, an attacker would – hopefully – not have the server’s private key, so as an attack vector Wireshark sniffing is not the most likely option. Nevertheless, the private key remains the single point of failure – if it is stolen, somebody could decrypt even past communication. So we could store all that encrypted traffic, hoping that we will at some point have access to that key and decrypt all of it.

Two more technologies help us to avoid this and make TLS even more secure.

The first is called TLS resumption and is explained in RFC 5077. It basically means that client and server are holding a “resumption ticket” from which they can pull session keys without the need for another handshake. If session resumption is in place, Wireshark might not see handshakes despite having several sessions re-established.

You might ask: Why is there a session key, anyway? Don’t we already have a private key with which we can enjoy encrypted communication? Well, this leads us to the second technology: Perfect forward secrecy. This means that even if somebody recorded all your encrypted connections from the past and then stole your private key, your past communication will not be decryptable with just that private key. Instead, the attacker would have had to steal all session keys for your encrypted sessions. This is a great enhancement in security and nowadays most websites do use this technique:

When you open the connection details in your browser, it will most likely tell you that the connection is encrypted with TLS_ECDHE. This means that TLS is used with Elliptic-curve Diffie–Hellman (ECDHE) as session key agreement protocol. In other words: In order to decrypt such a connection, somebody will have to steal that session key.

How to steal it, you might wonder?

Actually, it is incredibly easy to make Firefox and Chrome dump the session keys. Chrome at least shows a warning when this happens and Mozilla once had decided to disable that debugging feature for a while. At the end of the day however, developers came to the conclusion that if somebody is on your system and able to perform changes, you anyway have bigger problems. That’s certainly a valid point, but it also shows us that we really need to trust our browsers and that they are not doing strange things with our data. Or how SANS once put it: Psst, your browser knows all your secrets!