In this case, as I’ll be investigating the connection between and my machine, I’ll use host and port 443. For debugging HTTPS connections, you can usually get away with using host and port 443. The one it puts in this box is the Berkley Packet Filter language, which is very simple. For this reason, when you’re debugging you’ll likely want to filter the traffic down to just the things you want.Ĭonfusingly, Wireshark uses two filter languages. This is likely to include a lot of extraneous data from all of the stuff that’s going on in your computer. When you do a packet capture, most of the time you’ll be capturing on your computer’s primary network card. Let’s talk briefly about capture filters. Here we have two separate options: we can enter a capture filter, and we can select an interface to capture on.
This confronts us with a slightly intimidating white screen, but the things we’re most interested in are in the “Capture” section. I highly recommend using a Wireshark that’s at least version 2.0.0: the UI changed drastically for version 2 and is much cleaner and easier to work with. All the screenshots here are from Wireshark 2.0.1 on OS X El Capitan 10.11.3 Beta. I’m going to use the Chrome web browser to investigate this.
As we investigate the TLS protocol, we’ll also take a look at some places problems arise. In this case, we’re going to look at a healthy TLS connection, and drill down to how it works. After a while you can get good enough at this that you can use Wireshark to discover bugs in servers that you don’t operate and cannot reach, and so are effectively a black box, purely by examining TLS handshakes (trust me, there are loads of servers that don’t correctly perform TLS handshakes). It can help you spot problems and come up with ways to work around them. But OpenSSL rarely tells you what the actual problem was, usually because TLS has no good mechanism for communicating problems to the remote peer before terminating the handshake.įor this reason, it becomes extremely helpful to see into a TLS handshake and understand what’s going on. These range from wildly overgeneral (“bad handshake”? What is bad about it?) to the accurate but unhelpful (“EOF in violation of protocol”, no duh). If those tools work with OpenSSL, and you’ve ever seen them fail, you’ve likely seen one of OpenSSL’s cryptic error strings pop up in your face. Lots of us use tools that work with TLS on a regular basis, usually in the form of HTTPS URLs. Today, I’m going to talk about TLS, and Wireshark’s awesome functionality for trying to understand what happens when TLS goes wrong.
WIRESHARK ENCRYPTED ALERT SERIES
This may be the first in a series of posts where I demonstrate how I use Wireshark to investigate networks and to track down bugs in misbehaving implementations. Today I’m going to dive into my go-to debugging tool for network problems: Wireshark. This is a real shame, because some of the tools available to programmers working with computer networks are some of the coolest available to any programmer. This means that many of you don’t have a chance to experience some of the tools and debugging experiences that I do on a nearly daily basis. Sometimes in my darker moments I forget that not all programmers get to work with computer networks every day, like I do.
0 kommentar(er)
