(2) seems like the only reasonable option. We don't want to get stuck not being able to support newer TLS versions!
-Dan On Wed, Oct 24, 2018 at 11:23 AM Jinmei Liao <jil...@pivotal.io> wrote: > Most of our SSL tests failed with jdk11 because jdk11 includes an > implementation of TLS1.3 protocol, so if tcpServer is started with no > specific protocol (like "any"), then TLS1.3 will be used in the SSL > handshake, the TLS1.3 specs states: > Sessions[edit > <https://wiki.openssl.org/index.php?title=TLS1.3&action=edit§ion=5>] > > In TLSv1.2 and below a session is established as part of the handshake. > This session can then be used in a subsequent connection to achieve an > abbreviated handshake. Applications might typically obtain a handle on the > session after a handshake has completed using the SSL_get1_session() > <https://www.openssl.org/docs/manmaster/man3/SSL_get1_session.html> > function > (or similar). > > In TLSv1.3 sessions are not established until after the main handshake has > completed. The server sends a separate post-handshake message to the client > containing the session details. Typically this will happen soon after the > handshake has completed, but it could be sometime later (or not at all). > > Our SocketCreator has code that calls getSession immediately after a > handshake, which is only compliant with TLS1.2 protocol: > > sslSocket.startHandshake(); > SSLSession session = sslSocket.getSession(); > Certificate[] peer = session.getPeerCertificates(); > if (logger.isDebugEnabled()) { > logger.debug("SSL Connection from peer []", > ((X509Certificate) peer[0]).getSubjectDN()); > } > > > So the question is how to fix this in jdk11, here are some proposals: > 1) fix our test by specifying the protocol to be TLSv1.2 specifically. > 2) fix our code to not call getSession after startHandshake() since that > information is only used in a debug message. > > Any suggestions? > > > > -- > > Cheers > > Jinmei >
