|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Failure posting files to iis6.0 using ssl client authenticationwhen 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 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" <yar***@xor-t.com> wrote in message There seems to be a bug when posting a "large" file (30k) to IIS 6.0news:1113386439.589277.16820@g14g2000cwa.googlegroups.com... 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
IIS 6 conflict using port 443 for NON-SSL traffic
Intranet problem - 404 and 405 errors How to tell if IIS lockdown Tool is installed? client certificates Strange IIS 5 problem with client certificates NTFS permissions Anonymous access request certificate immediately Permission denied: 'CreateObject' - error '800a0046' Indexing Service, web page, no results... Permissions? |
|||||||||||||||||||||||