Ask Your Question
0

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

asked 2019-06-12 09:53:39 +0000

xjfromsh gravatar image

updated 2019-06-13 19:25:49 +0000

grahamb gravatar image

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

edit retag flag offensive close merge delete

Comments

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

Jaap gravatar imageJaap ( 2019-06-12 14:01:36 +0000 )edit
add a comment

1 Answer

Sort by ยป oldest newest most voted
1

answered 2019-06-12 17:13:11 +0000

grahamb gravatar image

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.

edit flag offensive delete link more

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 gravatar imagexjfromsh ( 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 gravatar imagegrahamb ( 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 gravatar imageLekensteyn ( 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 gravatar imagexjfromsh ( 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 gravatar imagexjfromsh ( 2019-06-14 03:34:32 +0000 )edit
see more comments

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

subscribe to rss feed

Stats

Asked: 2019-06-12 09:53:39 +0000

Seen: 6,218 times

Last updated: Jun 13 '19

Related questions

TLS1.2 Handshake failure

What is this protocl version sent in the TLS supported_versions extension?

haw can i export the certificate into form der from pcap file with command line tshark and not manually ??

TCP Retransmission during TLS-Handshake

Cause Of Server Hello Delay

Can't capture TLS certificate

How can I extract parameters from pcap

serverhello tls from proxy is encrypted

different TLS handshake versions in the ClientHello from the same client

Where can I find the TLS version that is being sent from the client through the ClientHello to the server? [closed]