Handle null SSLSessions during invalidation #34130
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The SSLService invalidates SSLSessions when there is a change to any of the underlying key or trust material. However, this invalidation code did not check for a null SSLSession being returned from the context and assumed that the context would always return a non-null object. The return of a null object is possible in all versions, but JDK11 seems to return them more often due to changes for TLS 1.3. There are a number of reasons that we get a id of a session but the context returns null when the session with that id is requested. Some of the reasons for this are: * Session was evicted by session cache * Session has timed out * Session has been invalidated by another caller To handle this, the SSLService now checks if the value is null before calling invalidate on the SSLSession. Closes elastic#32124
Collaborator
|
Pinging @elastic/es-security |
jaymode
added a commit
that referenced
this pull request
Sep 28, 2018
The SSLService invalidates SSLSessions when there is a change to any of the underlying key or trust material. However, this invalidation code did not check for a null SSLSession being returned from the context and assumed that the context would always return a non-null object. The return of a null object is possible in all versions, but JDK11 seems to return them more often due to changes for TLS 1.3. There are a number of reasons that we get a id of a session but the context returns null when the session with that id is requested. Some of the reasons for this are: * Session was evicted by session cache * Session has timed out * Session has been invalidated by another caller To handle this, the SSLService now checks if the value is null before calling invalidate on the SSLSession. Closes #32124
jaymode
added a commit
to jaymode/elasticsearch
that referenced
this pull request
Sep 28, 2018
Revert "[TESTS] Pin MockWebServer to TLS1.2 (elastic#33127)" (commit 214652d) and "Pin TLS1.2 in SSLConfigurationReloaderTests" (commit d9f5e4f), which pinned the MockWebServer used in the SSLConfigurationReloaderTests to TLSv1.2 in order to prevent failures with JDK 11 related to ssl session invalidation. We no longer need this pinning as the problematic code was fixed in elastic#34130.
jaymode
added a commit
that referenced
this pull request
Oct 2, 2018
Revert "[TESTS] Pin MockWebServer to TLS1.2 (#33127)" (commit 214652d) and "Pin TLS1.2 in SSLConfigurationReloaderTests" (commit d9f5e4f), which pinned the MockWebServer used in the SSLConfigurationReloaderTests to TLSv1.2 in order to prevent failures with JDK 11 related to ssl session invalidation. We no longer need this pinning as the problematic code was fixed in #34130.
kcm
pushed a commit
that referenced
this pull request
Oct 30, 2018
The SSLService invalidates SSLSessions when there is a change to any of the underlying key or trust material. However, this invalidation code did not check for a null SSLSession being returned from the context and assumed that the context would always return a non-null object. The return of a null object is possible in all versions, but JDK11 seems to return them more often due to changes for TLS 1.3. There are a number of reasons that we get a id of a session but the context returns null when the session with that id is requested. Some of the reasons for this are: * Session was evicted by session cache * Session has timed out * Session has been invalidated by another caller To handle this, the SSLService now checks if the value is null before calling invalidate on the SSLSession. Closes #32124
kcm
pushed a commit
that referenced
this pull request
Oct 30, 2018
Revert "[TESTS] Pin MockWebServer to TLS1.2 (#33127)" (commit 214652d) and "Pin TLS1.2 in SSLConfigurationReloaderTests" (commit d9f5e4f), which pinned the MockWebServer used in the SSLConfigurationReloaderTests to TLSv1.2 in order to prevent failures with JDK 11 related to ssl session invalidation. We no longer need this pinning as the problematic code was fixed in #34130.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The SSLService invalidates SSLSessions when there is a change to any of
the underlying key or trust material. However, this invalidation code
did not check for a null SSLSession being returned from the context and
assumed that the context would always return a non-null object. The
return of a null object is possible in all versions, but JDK11 seems to
return them more often due to changes for TLS 1.3. There are a number
of reasons that we get a id of a session but the context returns null
when the session with that id is requested. Some of the reasons for
this are:
To handle this, the SSLService now checks if the value is null before
calling invalidate on the SSLSession.
Closes #32124