1

We have a problem with RESTfull service running on Tomcat + APR/native. Server requires client authentication by certificate. The problem appears only if client supports TLS with session tickets (RFC 5077).

Here is what happens: when client performs initial handshake (full handshake) req.getAttribute("javax.servlet.request.X509Certificate") returns a valid certificate. Service looks up certificate in database and processes request if and only if an account identified by the certificate has sufficient amount of money.

During initial full handshake server transmits a SessionTicket towards client.

When client performs second request it transmits a SessionTicket towards server. Having a SessionTicket server does not make a CertificateRequest, so client doesn't transmit its Certificate. req.getAttribute("javax.servlet.request.X509Certificate") returns null.

The question is: what is the best practice to identify the client by its certificate (mutual TLS authentication)? Is there any way to inject some information into SessionTicket during initial full handshake and extract it during resumed handshake?

UPD1. Available request attributes during full handshake:

javax.servlet.request.ssl_session=219FE...
javax.servlet.request.ssl_session_id=219FE...
javax.servlet.request.key_size=256
javax.servlet.request.X509Certificate=[Ljava.security.cert.X509Certificate;@2a0ad546
javax.servlet.request.cipher_suite=DHE-RSA-AES256-SHA

Available request attributes during resumed TLS handshake:

javax.servlet.request.key_size=256
javax.servlet.request.cipher_suite=AES256-SHA
HolisticElastic
  • 937
  • 8
  • 17
  • 1
    You might have to do something fancy involving remembering the `javax.servlet.request.ssl_session_id` for a short time for accepted connections with client certificates. – user207421 Nov 19 '14 at 03:07
  • **EJP**, thanks for your advice! It was the first thing I tried (before asking the question), however, `ssl_session_id` is not available during resumed TLS handshake, at least not in Tomcat/APR/OpenSSL (look at UPD1 for what is available). – HolisticElastic Nov 19 '14 at 03:19
  • Interesting. I would say this is really a bug in Apache HTTPD or possibly OpenSSL or JSSE. It should provide all the same things for an SSL connection, even one that resumes a ticketed session. It all comes out of the SSL session so it's all available. – user207421 Nov 19 '14 at 04:42
  • Can I suggest that [Tomcat docs](http://tomcat.apache.org/tomcat-8.0-doc/ssl-howto.html) footnote "This is currently only available for the BIO and NIO connectors, not the APR/native connector." is an acknowledgment of this bug in APR? – HolisticElastic Nov 21 '14 at 14:08

0 Answers0