(SERVER-332) Allow all TLS algorithms in the dev lein profile #380
Conversation
This file contains 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
jeffmccune
force-pushed
the
s332_sslv3_vs_170u75
branch
from
497f529
to
ab2de68
Compare
| # SERVER-332 Disable no algorithms so that unit tests are able to exercise the | ||
| # behavior of the system when the end user explicitly configures deprecated | ||
| # algorithms like SSLv3. | ||
| jdk.tls.disabledAlgorithms= |
There was a problem hiding this comment.
If we need this properties file, I think it might be better to put it in "dev-resources". I think of that directory as containing files that are needed by tests and won't ever be changed by users, whereas I think of the "dev" directory as a place where users go to look for sample configs that they might modify, etc.
jeffmccune
force-pushed
the
s332_sslv3_vs_170u75
branch
from
ab2de68
to
289587d
Compare
|
@camlow325 mentioned it would be good to have new documentation about adjusting JAVA_OPTS if this is required in production. |
|
👍 |
Without this patch the unit tests fail on JVM versions more recent than 1.7.0_u75 because SSLv3 is disabled at the JRE layer by default. This is a problem because the end user may explicitly configure the JRE to allow SSLv3 algorithms, even though we disable them by default at the application layer, and we need to test the behavior of the system in this scenario. This patch addresses the problem by allowing all SSLv3 algorithms by overriding the java.security jdk.tls.disabledAlgorithms property. This patch employs an override file rather than passing -Djdk.tls.disabledAlgorithms= as a java option because passing the java option doesn't work. Similarly, passing `-Ddeployment.security.SSLv3=true` as a java option as mentioned at [1] does not have the desired effect of enabling SSLv3. The properties file is located in `dev-resources` because the directory contains files needed by the tests and shouldn't ever be changed by end users. [1]: http://www.oracle.com/technetwork/java/javase/7u75-relnotes-2389086.html
jeffmccune
force-pushed
the
s332_sslv3_vs_170u75
branch
from
289587d
to
005c7f6
Compare
|
That travis failure was weird but I'm +1 on this. |
cprice404
pushed a commit
that referenced
this pull request
Feb 3, 2015
(SERVER-332) Allow all TLS algorithms in the dev lein profile
| @@ -195,3 +195,34 @@ a multi-master environment or using an external CA, you might want to disable | |||
| the CA service on some nodes. | |||
|
|
|||
|
|
|||
| ## Java Secure Socket Extension (JSSE) configuration | |||
|
|
|||
There was a problem hiding this comment.
@nfagerlund FYI, we've added a note to the puppet server configuration documentation about how to re-enable SSLv3, if required.
Re-enabling SSLv3 is not advised, at all, due to POODLE.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Without this patch the unit tests fail on JVM versions more recent than
1.7.0_u75 because SSLv3 is disabled at the JRE layer by default. This is a
problem because the end user may explicitly configure the JRE to allow SSLv3
algorithms, even though we disable them by default at the application layer,
and we need to test the behavior of the system in this scenario. This patch
addresses the problem by allowing all SSLv3 algorithms by overriding the
java.security jdk.tls.disabledAlgorithms property.