SSL POST connection with client authentification dropped by IIS 5/W2000Server

SSL POST connection with client authentification dropped by IIS 5/W2000Server

am 10.02.2006 19:20:19 von Jean-Marc Desperrier

Hi,

We have a problem with a client installation when SSL POST connections
with client authentification are sometimes dropped by IIS 5/W2000
Server. Drops means a TCP FIN sent by IIS once the client has finished
sending his POST data, with not a single byte of data going from server
to client.

The problem only happens with some requests.
Except the exact length/content of the request, nothing differentiates
those requests from the other requests that are going through all right.
Some of those requests will go through after retrying, but some seem to
be really stuck. Only a small percentage of requests are affected by
this, the requests that fails are quite similar in size and content, but
we have not been able to isolate anything really special in them.
The difference in content between requests is only base64 encoded data.

We are not able to reproduce the problem on our local configuration,
despite our investigations showing that we were able to send the exact
same content on the network (we managed to have the exact same content
at the application level, POST headers, etc., some of the SSL parameters
might still be different).

Using the ssldump tool and the private key of the server, we were able
to trace exactly what happens (contents is anonymized).

The client opens the connection, negotiates an SSL session, send the
header data in one package, IIS requests to renegotiate the connection
with an "HelloRequest", the client send the rest of the data, and after
sending all of it begins renegotiation.

Then in the failing case, the web server immediately drops with TCP FIN.

In most cases, everything continues properly after that with no visible
difference within everything that happens before the point where IIS
drops the connection.

- the client opens the connection :
New TCP connection #1: 10.xx.xx.xx(63272) <-> 10.xx.xx.yyy(443)
1 1 0.0087 (0.0087) C>S SSLv2 compatible client hello
Version 3.1
cipher suites
[ Full list of cipher suites ]

- the server respond :
1 2 0.0163 (0.0076) S>C Handshake
ServerHello
Version 3.1
session_id[32]=
df 1d 00 00 b2 c7 5f 71 ea 35 7a ca b3 31 f5 43
25 9d a3 72 b7 5f d0 b7 bf f3 9e 18 62 0d aa fe
cipherSuite TLS_RSA_WITH_RC4_128_MD5
compressionMethod NULL
Certificate
[details of certificate follow]

- the rest of the SSL connection opening follows :
1 3 0.0305 (0.0141) C>S Handshake
ClientKeyExchange
1 4 0.0305 (0.0000) C>S ChangeCipherSpec
1 5 0.0305 (0.0000) C>S Handshake
Finished
1 6 0.0338 (0.0032) S>C ChangeCipherSpec
1 7 0.0338 (0.0000) S>C Handshake
Finished
1 8 0.0575 (0.0237) C>S application_data

- the client sends the headers :
1 8 0.0575 (0.0237) C>S application_data
------------------------------------------------------------ ---
POST /xxxxxxx.asmx HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: xxxxx.xxxxxx.xxx
User-Agent: libwww-perl/5.803
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://xxxxxxxxxx/xxxx"
Content-Length: 29208

------------------------------------------------------------ ---

- the server sends an hello request
1 9 0.0579 (0.0003) S>C Handshake
HelloRequest

- the client decide to send the data first in several packets
1 10 0.0666 (0.0086) C>S application_data
[a little less than 16Kb of data]
1 11 0.0741 (0.0074) C>S application_data
[the rest of data, around 15200 bytes]

- and to renegotiate only once it has finished
1 12 0.0741 (0.0000) C>S Handshake
ClientHello
Version 3.1
cipher suites
[ Full list of cipher suites ]
compression methods
NULL

- the server then drops the connection
1 0.0744 (0.0003) S>C TCP FIN
1 0.0921 (0.0176) C>S TCP FIN

In our configuration, just after this step instead of "S>C TCP FIN",
the connection goes on like this. This by the way is also exactly
similar to what happens on the client machine for requests that works :

1 13 0.3177 (0.1891) S>C Handshake
ServerHello
Version 3.1
session_id[32]=
8a 00 00 00 1a a4 1f b1 e5 97 47 c5 20 24 ca 83
0f d3 e3 63 0b b8 88 35 18 56 9e d6 d4 21 85 e4
cipherSuite TLS_RSA_WITH_RC4_128_MD5
compressionMethod NULL
Certificate
[details of certificat follow]

1 15 0.3310 (0.0000) C>S Handshake
ClientKeyExchange
1 16 0.3310 (0.0000) C>S Handshake
CertificateVerify
Signature[128]=
59 ad f3 69 4b 3b 14 76 04 8f c6 20 da 9e 58 9d
78 e0 5d 74 78 7e dd 0b 26 3b 45 36 40 6d ce a2
d5 a0 34 49 38 c4 28 d4 b5 d7 dc 5b 60 4e 58 47
33 3e f4 c1 2d 12 dd 3c 18 06 09 2b e8 1e d4 e7
93 97 b2 9d 76 a1 69 cd 99 68 50 09 fd 4b 78 ac
7a 1d 33 bf 77 cd 66 86 82 65 2c 81 4f 2c 35 33
33 43 b7 fe fc f2 97 13 64 9f c0 f0 59 d3 c3 d1
9a ef 23 3a 94 19 c1 b7 24 22 09 96 21 dd 7e ac
1 17 0.3310 (0.0000) C>S ChangeCipherSpec
1 18 0.3310 (0.0000) C>S Handshake
Finished
1 19 0.3354 (0.0043) S>C ChangeCipherSpec
1 20 0.3354 (0.0000) S>C Handshake
Finished
1 21 0.4346 (0.0992) S>C application_data
[... going on with sending back the response ...]

Re: SSL POST connection with client authentification dropped by IIS5/W2000 Server

am 13.02.2006 12:20:35 von Jean-Marc Desperrier

Jean-Marc Desperrier wrote:
> We have a problem with a client installation when SSL POST connections
> with client authentification are sometimes dropped by IIS 5/W2000
> Server. Drops means a TCP FIN sent by IIS once the client has finished
> sending his POST data, with not a single byte of data going from server
> to client.

I forgot to include questions in my message :

- Is this a known problem with IIS5/Windows 2000 ?

- If so, is there a description of what exact circumstances causes it,
so we could see how to cleanly work-around it ?