THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
0

TLS1.2 handshaking issue, need help, urgent, thanks a ton!

Hi, I encountered an issue while client and server TLS1.2 handshaking, so I am not able to send TLS1.2 data from client to server.

I recorded a wireshark trace file.

From the log, I can see following "Client hello, Server Hello,Change Cipher Spec, Encrypted Handshake Message" back and forth. But, I am not able to see the "Certificate, Server key exchange, Server Hello Done" package.

Is there anyone can help me understand what the root cause of it and how to fix this issue? Thanks so much!

Sorry I am not able to upload the trace file as my account is a new account.

Here is the Wireshark trace log snippet:

1726    2019-04-24 06:00:54.023885  stgcsgen3pt-1611270.lvs02.dev.ayc3.com  lvs-wfmqa-002.corp.ay.com   TLSv1.2 381 Client Hello

1732    2019-04-24 06:00:54.051177  lvs-wfmqa-002.corp.ay.com   stgcsgen3pt-1611270.lvs02.dev.ayc3.com  TLSv1.2 216 Server Hello, Change Cipher Spec, Encrypted Handshake Message

1734    2019-04-24 06:00:54.063671  stgcsgen3pt-1611270.lvs02.dev.ayc3.com  lvs-wfmqa-002.corp.ay.com   TLSv1.2 117 Change Cipher Spec, Encrypted Handshake Message

1736    2019-04-24 06:00:54.063833  stgcsgen3pt-1611270.lvs02.dev.ayc3.com  lvs-wfmqa-002.corp.ay.com   TLSv1.2 443 Application Data
...
1858    2019-04-24 06:01:09.162509  stgcsgen3pt-1611270.lvs02.dev.ayc3.com  lvs-wfmqa-002.corp.ay.com   TLSv1.2 381 Client Hello

1864    2019-04-24 06:01:09.187792  lvs-wfmqa-002.corp.ay.com   stgcsgen3pt-1611270.lvs02.dev.ayc3.com  TLSv1.2 216 **Server Hello, Change Cipher Spec, Encrypted Handshake Message

1866    2019-04-24 06:01:09.200101  stgcsgen3pt-1611270.lvs02.dev.ayc3.com  lvs-wfmqa-002.corp.ay.com   TLSv1.2 117 Change Cipher Spec, Encrypted Handshake Message

...

Best Regards -Jun

xjfromsh's avatar
1
xjfromsh
asked 2019-06-12 09:53:39 +0000
grahamb's avatar
23.8k
grahamb
updated 2019-06-13 19:25:49 +0000
edit flag offensive 0 remove flag close merge delete

Comments

Use any publicly accessible file sharing service to provide a capture file and provide a link here.

Jaap's avatar Jaap (2019-06-12 14:01:36 +0000) edit
add a comment see more comments

1 Answer

1

You have TLS session resumption so the TLS handshake is abbreviated, omitting the certificates and key exchange. If you application isn't working correctly, then either the client or server isn't correctly implementing session resumption.

grahamb's avatar
23.8k
grahamb
answered 2019-06-12 17:13:11 +0000
edit flag offensive 0 remove flag delete link

Comments

Hi, Thank you so much! Can you please help me understand how I can verify if the TLS session resumption is correct or not at client or server side? Where is it normally?

FYI Our client host is a Linux server and uses Stunnel to implement the TLS1.2 data transfer to the server. We have couple of client hosts, other clients are all good for TLS data transfer to the same server, only one client host has above issue. We tried to compare the configuration among each client, we didn't figure out any difference so far.

Thanks! Jun

xjfromsh's avatar xjfromsh (2019-06-13 02:41:16 +0000) edit

I think that determining what's gone wrong will require access to debug logs (if any) from the applications and\or the ability to debug the applications.

As usual, Wireshark can tell you what has happened, but not why.

grahamb's avatar grahamb (2019-06-13 19:28:09 +0000) edit

@xjfromsh Why do you think that lack of a Certificate and Key Exchange message is a problem? Session resumption speeds up further connections in TLS 1.2.

Lekensteyn's avatar Lekensteyn (2019-06-13 23:25:45 +0000) edit

@grahamb , below is the stunnel log on the client server. I saw before bold lines. But, I don't understand what's the meaning of it. Not sure if it is helpful? Thanks again!

2 15:39:45 LOG7[53200]:  53120 client connect(s) requested

2019.06.12 15:39:45 LOG7[53200]:  53116 client connect(s) succeeded

2019.06.12 15:39:45 LOG7[53200]:      0 client renegotiation(s) requested

2019.06.12 15:39:45 LOG7[53200]:  50423 session reuse(s)

2019.06.12 15:39:45 LOG6[53200]: TLS connected: new session negotiated

2019.06.12 15:39:45 LOG7[53200]: Deallocating application specific data for addr index

2019.06.12 15:39:45 LOG6[53200]: Negotiated TLSv1.2 ciphersuite ECDHE-RSA-AES256-GCM-SHA384 (256-bit encryption)

2019.06.12 15:39:45 LOG7[53200]: Compression: null, expansion: null

**2019.06.12 15:39:45 LOG6[53200]: TLS socket closed (SSL_read ...
(more)
xjfromsh's avatar xjfromsh (2019-06-14 02:51:02 +0000) edit

@Lekensteyn

Hi, no, I am not sure. I just saw there were a lot of repeated client hello/server hello/change Cipher messages in short seconds. That is abnormal. Also, the data transfer doesn't work. I am trying to figure out the reason.

xjfromsh's avatar xjfromsh (2019-06-14 03:34:32 +0000) edit
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer