Ask Your Question
0

SSL/TLS Handshake Immediately Fails

asked 2018-01-24 13:29:34 +0000

bhilgenkamp gravatar image

updated 2018-01-24 13:48:54 +0000

grahamb gravatar image

I'm seeing an odd behavior where immediately after the TCP handshake the SSL handshake fails; well it doesn't really fail, it just doesn't even try to start. There is not even a Client Hello sent. The interesting thing is that the server who began the conversation is the one who is terminating the connection. The application team recently made a change to force the application to use TLS 1.2 (disabled TLS 1.0/1.1) so I'm fairly confident this is due to that change. I would like to understand better when this is happening though so that I can relay that to the application owner. It seems odd that the server is terminating the connection even before trying to establish the TLS connection.

I'm new to the forum and apparently I need points to even post a screenshot so here is a link

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted
0

answered 2018-01-24 21:05:10 +0000

Bill Woodrow gravatar image

I would check the configuration at the application layer. The client (Java in your case) may not be configured to use TLSv1.2, so it could be as simple as disabling TLS1.0, and 1.1 and enabling 1.2 on the client side - similar as to how you might do this in a browser.

edit flag offensive delete link more

Comments

Seems like the app team may have done this. I don't know exactly what was changed - I was only told they "created Dynamic outbound endpoint SSL configurations specifically to [the application] using TLSv1.2 protocol in order to resolve this issue".

bhilgenkamp gravatar imagebhilgenkamp ( 2018-01-26 14:13:58 +0000 )edit
0

answered 2018-01-24 13:54:53 +0000

grahamb gravatar image

Usually a link to a capture file is better than an image.

In your case, it's the client sending the TLS Alert (handshake failure) and then closing the connection. Is the client capable of making a TLS1.2 connection, i.e. what OS, and environment is the client running in?

From the TLS RFC:

handshake_failure
      Reception of a handshake_failure alert message indicates that the
      sender was unable to negotiate an acceptable set of security
      parameters given the options available.  This is a fatal error.
edit flag offensive delete link more

Comments

I agree on the image vs capture file but our corporate web filtering here is pretty strict. I'm amazed I was even able to upload the image...

I was wondering the same about the client so I ran a test using Curl via command line on the same client to the same destination server. This was successful connecting over TLS 1.2 (confirmed via separate pcap) so it tells me this is likely something on the application side. The application runs in WebSphere 8.5.5.11 on RHEL 7, Java version 1.8.0.

The description of the handshake_failure indicates this should come at least after a ClientHello is sent. Since that isn't even attempted I found it very odd that this error is occurring at this stage of the conversation.

bhilgenkamp gravatar imagebhilgenkamp ( 2018-01-24 14:18:46 +0000 )edit

AFAIK, Java 1.8 should be able to manage a TLS 1.2 client connection straight out of the box, but I agree this is where you should look.

It does seem odd that the client is even attempting the connection if it can't handle TLS 1.2, but at least it gives you some clue as to where the issue lies. Is there any other hardware\software, involved between the client app and the traffic capture point as that might be modifying the traffic?

grahamb gravatar imagegrahamb ( 2018-01-24 14:33:55 +0000 )edit

The capture was done via tcpdump directly on the client with only a 'host x.x.x.x' filter

bhilgenkamp gravatar imagebhilgenkamp ( 2018-01-24 14:38:45 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2018-01-24 13:29:34 +0000

Seen: 11,537 times

Last updated: Jan 24 '18