Case Study: Capture at Both Ends

While the general rule of thumb is to capture at the client, or at least start there, sometimes it’s necessary to take captures at both ends of a connection. The client perspective will allow you to view the problem as it is seen from the client. The server perspective might show the same thing. Or, in some cases like this one, it will provide the reason for the problem.

The problem was that a webpage wouldn’t load. There were various errors and no real indication of the problem. While SSL was suspected, there was no proof. So, we started with a capture at the client.

From the client, the capture reveals it sent a TLSv1.2 Client Hello as expected. However, it then abruptly ends with a FIN with no server hello. Versions and ciphers were compared in the settings, but everything matched. More data was required.

Another capture point was setup on the server. Immediately, the problem was revealed. The server received a TLSv1.0 Client Hello instead of the v1.2 that was sent. This led to a failure in the SSL handshake.

As it turns out, a caching/optimizing appliance was in the middle changing the Client Hello due to a misconfiguration. This was discovered due to the S+* in the SYN packet. If you want to know what kind of caching appliance was used, you can Google that signature or view the filter options in the “tcp.options.” display filter list to see if you can spot the appliance name.