You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@geode.apache.org by Jinmei Liao <ji...@pivotal.io> on 2018/10/24 18:22:49 UTC

[DISCUSS]: SSL and jdk11

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&section=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

Re: [DISCUSS]: SSL and jdk11

Posted by Jinmei Liao <ji...@pivotal.io>.

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 <ab...@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 <on...@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 <ds...@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 <ji...@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&section=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

Re: [DISCUSS]: SSL and jdk11

Posted by Anthony Baker <ab...@pivotal.io>.

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 <on...@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 <ds...@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 <ji...@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&section=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
>>> 
>

Re: [DISCUSS]: SSL and jdk11

Posted by Owen Nichols <on...@pivotal.io>.

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 <ds...@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 <ji...@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&section=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
>>

Re: [DISCUSS]: SSL and jdk11

Posted by Dan Smith <ds...@pivotal.io>.

(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 <ji...@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&section=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
>