SSLSocket renegotiation issue (JSSE)

[Mueller, Steffen (AIFB)]

Hi,





We have previously posted the following questions at jdk8-dev at openjdk.java.net<mailto:jdk8-dev at openjdk.java.net> in a slightly different version - we have some further insights, since we have posted the questions the last time. A member of jdk8-dev at openjdk.java.net<mailto:jdk8-dev at openjdk.java.net> advised us to post the questions here again...



We did not find anything regarding our questions in the archive or in the Web. We have some questions regarding the renegotiation of SSLSockets (JSSE).

Preconditions:

-          We installed the OpenJDK 8 update 40 (+ JCE unlimited strength policies) to run a distributed system that replicates its state over SSL-based socket connections

-          It is a peer-to-peer system. So, there is a set of socket connections between the various nodes of the distributed system

-          We only allow TLS 1.2 connections, so we get the SSLContext within the application by invoking:

SSLContext ctx = SSLContext.getInstance("TLSv1.2");
KeyManager[] kms = KeyManagerFactory.getInstance("SunX509").getKeyManagers();
TrustManager[] tms = TrustManagerFactory.getInstance("SunX509").getTrustManagers();
ctx.init(kms, tms, null);

-          Furthermore, we enable a list of cipher suites for socket, i.e., we invoke socket.setEnabledCipherSuites(new String[]{"TLS_RSA_WITH_AES_128_CBC_SHA","TLS_RSA_WITH_AES_256_CBC_SHA","TLS_DHE_RSA_WITH_AES_128_CBC_SHA",...});



Goal:

After the connection is established and used by the nodes to communicate their states within the cluster, we need to renegotiate the SSL connection after a while. Additionally, we want to change the negotiated cipher suite. For example, if the negotiated cipher suite is "TLS_RSA_WITH_AES_256_CBC_SHA" we want to change the cipher suite to "TLS_RSA_WITH_AES_128_CBC_SHA". So, we invoke:


socket.setEnabledCipherSuites(new String[]{"TLS_RSA_WITH_AES_128_CBC_SHA"});

if(!resume)

socket.getSession().invalidate();
socket.startHandshake();



Problem:

However, the cipher suite does not change (neither resume = true nor resume = false). Even the renegotiation is not always performed. A previously registered HandshakeCompletedListener is not invoked anyway. And if the debug log indicates that the handshake have been performed the previously negotiated cipher suite ("TLS_RSA_WITH_AES_256_CBC_SHA") is used again. The debug log does not give us any hint what could be wrong.

We tested the renegotiation procedure on an adjusted JDK-Test case (RejectClientRenego)... It works. However, in the test case (RejectClientRenego) the application layer does not send any application data to the SSLSocket while the renegotiation is being done... Furthermore, the test case is a single thread case. In our system multiple worker threads communicate over one socket connection and the renegotiation is invoked by a JMX MBean.



So, we have the questions: Are we doing something wrong? Is it possible/allowed to renegotiate the cipher suite for a connected socket which is used continuously by the application layer while the renegotiation is performed? Following the Javadoc of javax.net.ssl.SSLSocket.startHandshake() this should be possible ("If data has already been sent on the connection, it continues to flow during this handshake. When the handshake completes, this will be signaled with an event."). Do you have any other hints to solve our problems/to implement the desired behavior? ...





Thanks

Steffen Mueller

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20150505/84e516a3/attachment.htm>