Failure posting files to iis6.0 using ssl client authentication

There seems to be a bug when posting a "large" file (30k) to IIS 6.0
when using ssl client authentication.
All other scenarios, server authentication or no ssl at all work fine.
The bug does not occur with IIS 5.0.

Can someone provide a solution?

This is the full description of the bug (the solution is not clear):

//snip from the rc2 iis6.0 help
//=============================
If client certificates are enabled on individual directories or files
instead of the whole Web site, the following issue may arise:

The client sends a long HTTP request (such as POST) to a computer
running a
member of the Windows .NET Server 2003 family with IIS 6.0.
The IIS worker process receives enough data to parse request headers,
but
not the entire request entity body.
The IIS worker process detects that client certificates are required
for a
return of data to the client.
IIS tries to renegotiate the connection with the client.
The client cannot renegotiate because it is waiting to send the
remaining
data in the request to IIS.
The solution is to assure that client is not blocked from sending the
entire
entity body. If client renegotiation is requested, it is necessary to
preload the request entity body using SSL preload. SSL preload will use
the
value of UploadReadAheadSize used for ISAPI extensions. However, if
UploadReadAheadSize is smaller than Content length, then an HTTP Error
413
is returned and the connection is closed to prevent deadlock. (Deadlock

occurs because a client is waiting to complete sending a request
entity,
while the server is waiting for renegotiation to complete, but
renegotiation
requires that the client to be able to send data, which it cannot).
//snip

Re: Failure posting files to iis6.0 using ssl client authentication

Actually...

1. You have already posted the solution as well as rationale. It is not
clear to me what is confusing. UploadReadAheadSize needs to be large enough
to load the SSL POST entity body such that on Client Certificate
renegotiation that deadlock does not happen. I think that if more details
were given, it would be more confusing because most people who know about
SSL Client Certificate authentication do not understand the underlying
protocol nor flaws in the public SSL Client Certificate authentication spec
that result in this issue.

2. IIS5 has a bug such that this scenario worked by accident. IIS6 fixed
the bug correctly and securely. The ramification is described in the
solution/rationale you found.

3. Windows Server 2003 SP1 has been released already, so you should not be
using RC2

30K upload should work because default UploadReadAheadSize is 48K -- unless
you have some server-side application that changed it. If you do not know
about UploadReadAheadSize, I recommend searching microsoft.com for the term
and reading documentation.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"hugo" wrote in message
news:1113386439.589277.16820@g14g2000cwa.googlegroups.com...
There seems to be a bug when posting a "large" file (30k) to IIS 6.0
when using ssl client authentication.
All other scenarios, server authentication or no ssl at all work fine.
The bug does not occur with IIS 5.0.

Can someone provide a solution?

This is the full description of the bug (the solution is not clear):

//snip from the rc2 iis6.0 help
//=============================
If client certificates are enabled on individual directories or files
instead of the whole Web site, the following issue may arise:

The client sends a long HTTP request (such as POST) to a computer
running a
member of the Windows .NET Server 2003 family with IIS 6.0.
The IIS worker process receives enough data to parse request headers,
but
not the entire request entity body.
The IIS worker process detects that client certificates are required
for a
return of data to the client.
IIS tries to renegotiate the connection with the client.
The client cannot renegotiate because it is waiting to send the
remaining
data in the request to IIS.
The solution is to assure that client is not blocked from sending the
entire
entity body. If client renegotiation is requested, it is necessary to
preload the request entity body using SSL preload. SSL preload will use
the
value of UploadReadAheadSize used for ISAPI extensions. However, if
UploadReadAheadSize is smaller than Content length, then an HTTP Error
413
is returned and the connection is closed to prevent deadlock. (Deadlock

occurs because a client is waiting to complete sending a request
entity,
while the server is waiting for renegotiation to complete, but
renegotiation
requires that the client to be able to send data, which it cannot).
//snip

Re: Failure posting files to iis6.0 using ssl client authentication

Actually...

1. You have already posted the solution as well as rationale. It is not
clear to me what is confusing. UploadReadAheadSize needs to be large enough
to load the SSL POST entity body such that on Client Certificate
renegotiation that deadlock does not happen. I think that if more details
were given, it would be more confusing because most people who know about
SSL Client Certificate authentication do not understand the underlying
protocol nor flaws in the public SSL Client Certificate authentication spec
that result in this issue.

2. IIS5 has a bug such that this scenario worked by accident. IIS6 fixed
the bug correctly and securely. The ramification is described in the
solution/rationale you found.

3. Windows Server 2003 SP1 has been released already, so you should not be
using RC2

30K upload should work because default UploadReadAheadSize is 48K -- unless
you have some server-side application that changed it. If you do not know
about UploadReadAheadSize, I recommend searching microsoft.com for the term
and reading documentation.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"hugo" wrote in message
news:1113386439.589277.16820@g14g2000cwa.googlegroups.com...
There seems to be a bug when posting a "large" file (30k) to IIS 6.0
when using ssl client authentication.
All other scenarios, server authentication or no ssl at all work fine.
The bug does not occur with IIS 5.0.

Can someone provide a solution?

This is the full description of the bug (the solution is not clear):

//snip from the rc2 iis6.0 help
//=============================
If client certificates are enabled on individual directories or files
instead of the whole Web site, the following issue may arise:

The client sends a long HTTP request (such as POST) to a computer
running a
member of the Windows .NET Server 2003 family with IIS 6.0.
The IIS worker process receives enough data to parse request headers,
but
not the entire request entity body.
The IIS worker process detects that client certificates are required
for a
return of data to the client.
IIS tries to renegotiate the connection with the client.
The client cannot renegotiate because it is waiting to send the
remaining
data in the request to IIS.
The solution is to assure that client is not blocked from sending the
entire
entity body. If client renegotiation is requested, it is necessary to
preload the request entity body using SSL preload. SSL preload will use
the
value of UploadReadAheadSize used for ISAPI extensions. However, if
UploadReadAheadSize is smaller than Content length, then an HTTP Error
413
is returned and the connection is closed to prevent deadlock. (Deadlock

occurs because a client is waiting to complete sending a request
entity,
while the server is waiting for renegotiation to complete, but
renegotiation
requires that the client to be able to send data, which it cannot).
//snip