This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Client sends FIN immediately after SSL Handshake

0

One of the user is not able to open a ssl website,after capture there is a below pattern,immediately after SSL handshake client is sending FIN packet.what could be reason for this.Client machine is xp and domain which he is trying has a multi domain certificate.

1) Client sends [SYN] to server.
2) Server sends [SYN,ACK] to client.
3) Client sends [ACK] to server.
4) Client sends the message “Client Hello” to the server.
5) Server sends its public key with the message “Server Hello, Certificate, Server Hello Done”
6) Client sends its public key with the message “Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message”
7) Server sends encrypted handshake message with the message “Change Cipher Spec, Encrypted Handshake Message”
8) Client sends [FIN,ACK]
9) Server sends RST

asked 25 May '14, 05:25

kishan%20pandey's gravatar image

kishan pandey
221●28●29●36
accept rate: 28%

edited 25 May '14, 05:26

Jasper's gravatar image

Jasper ♦♦
23.8k●5●51●284

4 Answers:

1

You mentioned Windows XP. In the capture, I can see that the certificates are signed with a SHA256 ("SHA-2") algorithm. The older Windows XP versions do not support this algorithm, you need to have at least Windows XP SP3 for supporting these certificates.

See also this MS KB article: Windows Server 2003 and Windows XP clients cannot obtain certificates from a Windows Server 2008-based certification authority (CA) if the CA is configured to use SHA2 256 or higher encryption.

answered 30 Jun '14, 10:37

Lekensteyn's gravatar image

Lekensteyn
2.2k●3●7●24
accept rate: 30%

Great information,thanks for giving your thoughts.

(01 Jul '14, 04:54) kishan pandey

I see you have asked many questions here, please consider marking some as answered and/ or voting on them if you consider them helpful.

(01 Jul '14, 05:36) Lekensteyn

0

Looks like the client either only wanted to check if the server is still alive, or it was not happy with the something the server sent. You should do a capture of one of the users that is able to access the website and determine the differences.

answered 25 May '14, 05:29

Jasper's gravatar image

Jasper ♦♦
23.8k●5●51●284
accept rate: 18%

Uploading a capture - https://www.cloudshark.org/captures/34eb13edbb31

(25 May '14, 05:50) kishan pandey

what is the name of the server you are accessing?

(25 May '14, 12:01) Kurt Knochner ♦

https://current-uk.nadlcorp.com

(25 May '14, 22:52) kishan pandey

0

Looks like packet loss between the client and the server. There are Dup ACK's and Retransmissions. Seems that some of the ACK's are not making it from the client to the server, then after a while, they give up and tear down the connection.

It's also worth noting that the server does not support SACK, and has a MSS of 956 bytes. Possibly some security device modifying the TCP options.

answered 25 May '14, 11:02

Rooster_50's gravatar image

Rooster_50
238●9●12●18
accept rate: 15%

Loadbalancer is sitting on top of server and may be modifying it,if you see the IP.TTL field you will see that TTL during tcp handshake and ssl handshake is different because Loadbalancer is taking care of tcp handshake and ssl is by server.

(25 May '14, 22:59) kishan pandey

0

The client does not send the FIN immediately after the SSL handshake. alt text

GET request from Microsoft CryptoAPI alt text

GoDaddy CA Certificate alt text

answered 25 May '14, 21:35

mrEEde's gravatar image

mrEEde
3.9k●15●22●70
accept rate: 20%

edited 25 May '14, 23:05

Thanks,even i noticed it but not sure that this could be causing it,if i extract the Intermediate CA certificate received from above http request,it matches the one with received in server hello.

(25 May '14, 22:55) kishan pandey

Do you have the Go Daddy Root Certificate installed as trusted?

(25 May '14, 23:06) mrEEde

Hi,yes it has root certificate installed.

(01 Jun '14, 03:30) kishan pandey