This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Java SSL Problem

0

Can someone help me interpret what's going on this session? It's posted here:

http://cloudshark.org/captures/ded1b1cab975 line 229 - 238 is an example but there are others in the capture. I'm wondering if the SSL is being fragmented given that it's running over a VPN.

I am having app problems where I get a flood of disconnects throughout the day. Java debug that I get: Error SSL connecting to host:8444: java.net.SocketException: Connection reset Cause: java.net.SocketException: Connection reset and, java.net.MalformedURLException: unknown protocol: socket

asked 15 Oct '13, 17:51

chax8cam's gravatar image

chax8cam
11112
accept rate: 0%

There is a pattern to your trace file. Go to Statistics, Conversations, TCP tab. Sort by relative start and you will notice a pattern (will explain later). But first thing is first. Pkts 229-238, this is an example of an error condition? I don't see the client socket # in your post, so I'm asking. Or are the rejected connections the error condition? There are connections that are refused, that lasts ~5 secs, that lasts ~10 seconds. Which is the error condition?

(16 Oct '13, 05:47) hansangb

There is a pattern to your trace file.

The pattern you detected are (most certainly) service checks from the systems with IP address 172.18.21.x to two SSL servers (10.20.4.55 and .56.) These checks run every 60 seconds and are basically TCP connection attempts to check if something is alive and responds. Those are the connections with 7 or 9 frames.

You should exclude those conversations (due to misleading RESETS) and then look if there are any remaining problems.

(16 Oct '13, 07:25) Kurt Knochner ♦

This doesn't look like a fragmentation problem to me. Rather, it looks like a failed SSL session negotiation. Using the display filter "tcp.stream eq 9" isolates the particular TCP stream you referenced (229 - 238). After the three-way handshake, the client (172.18.21.5) appears to establish an SSL session with a cached session ID. The server (10.20.4.56) responds by sending a server hello and certificate chain, but with a different Session ID. The client responds with a PreMaster secret, but apparently the server doesn't like it because it responds with a TCP RST.

I am not familiar enough with SSL handshakes to understand the failure in detail - I'm sure someone much more knowledgeable will respond with that. But I'm wondering if the server is configured to accept renegotiated SSL sessions?? As a manager of an appliance which terminates SSL sessions, I have the ability to turn that option on/off. I'm wondering if something like that that might be at play here...

(16 Oct '13, 08:31) smp

Thanks SMP...very helpful insight where I can follow-up.

I believe that packets 229-238 is a probe that is failing and continues to do so throughout the capture. In other words the error condition is the failing probe.

I captured a different a client and session that is purported to be a good probe for comparison sake. It shows the client, 172.18.x.x sending the RST as opposed to the server, 10.20.4.56:
http://www.cloudshark.org/captures/2b350c4a3e60

I re-posted the original capture and filtered only the 172.18.21.5 client which was in error the entire time.

Appreciate your help!

(16 Oct '13, 08:54) chax8cam