Server sends Encrypted Handshake right after Server Hello

handshakessl

During investigation of a Mutual SSL Authentication problem for webservice, I've traced with wireshark a working behaviour between a SOAP UI client and the server in order to understand how it behaved as I noticed something weird.

I still notice the same weird behaviour when handshake and communication is correct between client and server; which is the following:

 37. Client -> Server:    Client Hello
 54. Server -> Client:    Server Hello, Certificate
 61. Server -> Client:    Encrypted Handshake Message
 62. Client -> Server:    Certificate, Client Key Exchange
 64. Client -> Server:    Certificate Verify
 65. Client -> Server:    Change Cipher Spec
 66. Client -> Server:    Encrypted Handshake Message
 69. Server -> Client:    Change Cipher Spec
 74. Server -> Client:    Encrypted Handshake Message
 75. Client -> Server:    Application Data
 ...
434. Server -> Client:    Application Data
686. Server -> Client:    Encrypted Alert

Everything seems pretty normal to me except line 61 which is encrypted.
It surely contains "Certificate Request" and "Server Hello Done" since everything works fine (and client provides its own certificate line 62), but I have absolutely no understanding how message line 61 can be encrypted since I do not understand how client and server could have exchanged sufficient data to encrypt anything so soon.

Cipher Suite used by server is TLS_RSA_WITH_AES_128_CBC_SHA.

Any insight about how it could be encrypted so early may help me solve the problem I'm investigating, since the non-working client sends TCP RST right after receiving the Encrypted Handshake Message.

Best Answer

After deep investigation, it actually looks like there is no real Encrypted Handshake Message: wireshark fails to regroup handshake records when they're split. The Encrypted Handshake Message is actually an artifact due to this problem.

Since record max length is 2^14 bytes, whenever a handshake message is longer, it is split over multiple records.

Wireshark as well as my "failing client" seem to fail reconstructing these split records. Looks like a known unfixed bug in wireshak: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3303

Related Topic