Wireshark/HTTPS

Sniffing HTTPS with Wireshark

Over on the Man in the Middle/Wired/ARP Poisoning and Anonymous Browsing pages, I mention the danger of man-in-the-middle attacks and traffic sniffing, and the protection that HTTPS can offer you by encrypting your traffic.

However, it's also important to understand what HTTPS does NOT protect. For example, HTTPS does not protect the destination of the traffic. This is nuanced, however, so a novice unfamiliar with Wireshark might be tricked into thinking that HTTPS is hiding the destination of their HTTPS traffic. It is not.

When you use HTTPS, you prevent a man-in-the-middle attacker from being able to decrypt traffic - that would require your private key.

However, if an attacker had access to your machine, they could steal your private key and use it to decrypt your HTTPS traffic with Wireshark (http://htluo.blogspot.com/2009/01/decrypt-https-traffic-with-wireshark.html and https://support.citrix.com/article/CTX116557 and http://packetpushers.net/using-wireshark-to-decode-ssltls-packets/).

When you use HTTPS and experience a man-in-the-middle attack, you are presented with a warning that the certificate appears invalid.

However, if you accept that certificate, even once, the browser will permanently store it in a database, and it will be very difficult to remove. Once the certificate is accepted and is in your browser's database, the browser will never warn you when that certificate is being used, meaning an attacker can conduct a man-in-the-middle at any time without you being aware. This means accepting phony certificates, which is as easy as a single click of a button of an impatient and confused Sheep, has enormous implications.

Scary, ain't it?

Example HTTPS Traffic in Wireshark

Let's look at an example. I'll fire up a browser and visit https://en.wikipedia.org and I log in with my MediaWiki username and password. An attacker performing a man-in-the-middle attack can sniff my traffic. Mostly, they see traffic passing between my browser and a certificate authority (multiple IP addresses, but all registered under Verisign, a Certificate Authority.) HTTPS packets going to external addresses can't be sniffed because those are going through encrypted HTTPS tunnels that wireshark doesn't "see".

All of those SSL and TCP packets are going between the IP address browsing MediaWiki, and IP addresses belonging to Verisign.com, a Certificate Authority.

Determining HTTPS Traffic Destination

HOWEVER, an attacker can still see the destination of HTTPS traffic!!! While your traffic consists almost entirely of TCP packets between you and a certificate authority (IP addresses owned by Verisign), there is one key packet that an attacker may look at to see the destination of your HTTPS traffic by looking through a Wireshark traffic dump: the "Server Hello, Certificate, Server Hello Done" packet.

When you open this packet, you will see the packet contains a certificate. This is the certificate coming from the server, to whom the request is going to. In the photo above you can see clearly that despite the Sheep's use of HTTPS, someone performing a man-in-the-middle attack can still sniff the Sheep's connection.

So HTTPS traffic will protect the contents, but NOT the destination, of your traffic.

Not to mention, HTTPS can be beat during a man-in-the-middle attack using SSLStrip.

Sometimes Destinations are More Obvious

I guess that SSL certificates differ in how much information gets broadcast, because my cheapie self-signed certificate made it a lot easier to see the destination of HTTPS traffic destined for my website. It was not routed through Verisign.