[Pki-devel] SSL handshake problem

[Nathan Kinder]

Adding Elio for real this time...

On 08/17/2012 02:07 PM, Nathan Kinder wrote:
> Adding Elio to the thread in case he has any thoughts on this...
>
> On 08/16/2012 11:49 AM, Endi Sukma Dewata wrote:
>> Hi,
>>
>> I'm having a problem running a CLI operation on Dogtag 10 which seems 
>> to be caused by SSL handshake issue. Here are the steps to reproduce:
>>
>> 1. Get the latest Dogtag 10 source code.
>> 2. Apply the attached pki-certrequest.patch.
>> 3. Get the pki-dev tools (see 
>> http://pki.fedoraproject.org/wiki/Testing).
>> 4. Execute these commands in pki-dev/scripts to build and install CA:
>>
>>  % ./theme-build.sh
>>  % ./theme-install.sh
>>  % ./core-build.sh
>>  % ./core-install.sh
>>  % ./ds-create.sh
>>  % ./ca-create.sh
>>
>> 5. Then execute these test commands in pki-dev/scripts:
>>
>>  % ./cert-request-submit.sh cert-request.xml (note the Request ID)
>>  % ./cert-request-review.sh <Request ID> review.xml
>>  % ./cert-request-approve.sh review.xml
>>
>> Both review and approve operations are done via SSL and they require 
>> client certificate authentication. However, the review works, but the 
>> approve operation fails with HTTP code 401 (Unauthorized). This is 
>> because the review is a GET operation which doesn't send any data, 
>> but the approve is a POST operation which sends a relatively large data.
>>
>> These commands use Apache HTTP Client library which has a parameter 
>> called MIN_CHUNK_LIMIT (see 
>> http://hc.apache.org/httpcomponents-core-ga/httpcore/apidocs/org/apache/http/params/CoreConnectionPNames.html). 
>> The parameter is set to 512 bytes by default, so any request longer 
>> than that (such as the approve request) may be sent in multiple chunks.
>>
>> It seems that the current Tomcat JSS doesn't properly handle a 
>> request sent in multiple chunks. Currently the 
>> JSSSocketFactory.handshake() is not doing the handshake. The initial 
>> handshake is actually done when the server starts reading the data 
>> stream, without asking for the client certificate. Then when the 
>> server needs to get the client certificate it will do an SSL 
>> renegotiation in JSSSupport.getPeerCertificateChain(). For some 
>> reason the renegotiation fails if the request is sent in multiple 
>> chunks.
>>
>> One possible solution is to fix either Tomcat JSS, JSS, or NSS to 
>> handle multiple request chunks properly. We'll need an expert in this 
>> area to investigate and fix it.
>>
>> Another solution is to raise the MIN_CHUNK_LIMIT on the client, but 
>> there's a hard limit of 8 KB and there might be 3rd party clients 
>> which we can't control.
>>
>> Another possibility is we might be able to remove the requirement for 
>> renegotiation (still to be confirmed). Originally the renegotiation 
>> is needed to access some pages in Dogtag Web UI so it will prompt for 
>> client certificate. In Dogtag 10 we're doing some reorganization so 
>> renegotiation might not be needed anymore. In general unprotected UI 
>> pages would be accessed via unsecured port, but when the user tries 
>> to access a protected page he will be redirected to a secured port. 
>> Here the client certificate will be asked during the initial 
>> negotiation. Since there is no unauthenticated SSL connection, there 
>> is no need for renegotiation.
>>
>> Assuming we don't need renegotiation anymore, I attached a patch for 
>> Tomcat JSS (tomcatjss-handshake.patch) to do the initial negotiation 
>> in JSSSocketFactory.handshake() that will also ask for the client 
>> certificate. With this patch the approve operation will work 
>> properly. Is this the right solution? Are there other solutions?
>>
>> Thanks.
>>
>>
>>
>> _______________________________________________
>> Pki-devel mailing list
>> Pki-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/pki-devel
>
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120817/21fd2c44/attachment.htm>