2
votes

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.

1
(1) You're sure 61 is part of this connection and not another that was going on previously? Given one pair of addresses and the server is usually on a fixed port, the client port is what varies. (2) The protocol doesn't actually say "encrypted" so Wireshark assumes anything it can't decode is encrypted. You're right that what should be there (for that agreed ciphersuite) is CertReq and ServerHelloDone and both of those should be easy to decode, but look at the bytes (in the byte pane, usually bottom or right depending on the layout you've chosen). - dave_thompson_085
The Certificate message would only be present if requested by a CertificateRequest. - user207421
After deeper look: wireshark seems not to decode the Server -> Client Multiple Handshake Message properly: line 54. is more than Server Hello + Certificate but "Length" is set at 16 384 (max length based on RFC 5246). I'll dig deeper, but it looks like this early Encrypted Handshake Message is just side effect for wireshark to tell it does not understand anything about message content. - Julien Sauvard
So the Certificate Request is actually there and is of huge length: 15 979 bytes. Wireshark bugs on decoding SSL frame as header length is 16 384 and it truncates at this length; thus truncating the Certificate Request message. Thanks Dave and EJP for helping. I now have to understand if this is normal behaviour from server or not and if server or client needs a fix. - Julien Sauvard
The CertificateRequest contains all the CAs the server will accept, so it will be large. - user207421

1 Answers

2
votes

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