[Pki-devel] SSL handshake problem

[Endi Sukma Dewata]

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.

-- 
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-certrequest.patch
Type: text/x-patch
Size: 3461 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120816/3e8c3443/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tomcatjss-handshake.patch
Type: text/x-patch
Size: 1576 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120816/3e8c3443/attachment-0001.bin>