The following is a snapshot description of the problem experienced when we try and establish an SSL session our embedded device (4500) which contains an SSL (V3.1) client and the Cisco concentrator (SSL Server).
This information was obtained from sniffing the message exchange.
A TCP session is established - this consists of 3 messages being exchanged (3 way handshake):
4500->Cisco (TCP SYN)
Cisco->4500 (TCP SYN ACK)
4500->Cisco (TCP ACK)
An SSL CLIENT_HELLO message is sent from the 4500. This message is broken up over two TCP packets. The first contains just the 5 bytes of the TLS record protocol header as follows:
16 03 01 00 53 (16 = handshake content, version 3.1, length 0x53)
Second message contains the actual CLIENT_HELLO message - random number, cipher suite options etc.)
At this point the Cisco sends back a TCP FIN - no SSL content (no SSL Alert or other clue as to what the problem was).
A couple of other observations:
The TCP FIN sent by Cisco may be sent out even before the 4500 sends out the 2nd packet with the CLIENT_HELLO data. Which comes first may be a race condition. The Cisco end may have decided to end things immediately upon receiving the packet with the incomplete record.
Also the CLIENT_HELLO data occasionally contains a session ID which may/may not be valid.
So the question is - how can we gather information on the Cisco as to why it's (abruptly) ending the session?