[Pki-devel] SSL handshake problem
Nathan Kinder
nkinder at redhat.com
Fri Aug 17 21:26:56 UTC 2012
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>
More information about the Pki-devel
mailing list