Looks like we have a consensus on this one. I will implement the 2nd option then.
On Wed, Oct 24, 2018 at 11:59 AM Anthony Baker <aba...@pivotal.io> wrote: > If possible I don’t think we should have any code that is conditional > based on TLS version. > > Anthony > > > > On Oct 24, 2018, at 11:41 AM, Owen Nichols <onich...@pivotal.io> wrote: > > > > If Geode code is tightly coupled to the TLS protocol version, might be > good to have some tests that explicitly test how Geode handles both TLSv1.2 > and TLSv1.3 connections, when running under Java version that supports > TLSv1.3 > > > > The code example you gave looks like it is just debug logging that is > getting the session prematurely, should be easy to fix (or conditionalize > on TLS version)? > > > > > >> On Oct 24, 2018, at 11:26 AM, Dan Smith <dsm...@pivotal.io> wrote: > >> > >> (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 > >>> > > > > -- Cheers Jinmei
