Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security: remove SSL settings fallback #36846

Merged
merged 21 commits into from
Jan 14, 2019
Merged

Conversation

jaymode
Copy link
Member

@jaymode jaymode commented Dec 19, 2018

This commit removes the fallback for SSL settings. While this may be
seen as a non user friendly change, the intention behind this change
is to simplify the reasoning needed to understand what is actually
being used for a given SSL configuration. Each configuration now needs
to be explicitly specified as there is no global configuration or
fallback to some other configuration.

Closes #29797

This commit removes the fallback for SSL settings. While this may be
seen as a non user friendly change, the intention behind this change
is to simplify the reasoning needed to understand what is actually
being used for a given SSL configuration. Each configuration now needs
to be explicitly specified as there is no global configuration or
fallback to some other configuration.

Closes elastic#29797
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security

@gwbrown
Copy link
Contributor

gwbrown commented Dec 27, 2018

I've added this to the list of things we should add deprecation checks for in #36024 - would you be able to either:

  1. Add a deprecation check for this, or
  2. Have a brief sync when you're available so I can better understand what the user impact of this change is and how to check for needed configuration changes?

@jaymode
Copy link
Member Author

jaymode commented Jan 7, 2019

@gwbrown I added checks in the 6.x version #36847

docs/reference/settings/security-settings.asciidoc Outdated Show resolved Hide resolved
@@ -1380,23 +1276,21 @@ a PKCS#12 container includes trusted certificate ("anchor") entries look for

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we move the PKCS11 related settings to the http/transport related settings ? These feel strangely placed as is

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have them there as general information. @lcawl do you have a suggestion on where we should put this info?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I'm understanding correctly, that PKCS#11 already appears under the appropriate HTTP and Transport sections. So unless there are other contexts where there would be PKCS#11 settings, I think it can be removed from the "default values..." section.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we reference PKCS#12 in those sections but not PKCS#11

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Scratch that. I am wrong, we already have it there. So it can be removed from the defaults section

those configured in the `xpack.security.transport.ssl.truststore` and
`xpack.security.transport.ssl.certificate_authorities` settings. It also
includes certificates that are used for configuring server identity, such as
`xpack.security.transport.ssl.keystore` and
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we use the http layer as an example for certficate and keystore so that it becomes (even more) obvious that certificates used in both layers will be returned ?

@@ -231,14 +190,6 @@ private static TrustConfig createCertChainTrustConfig(Settings settings, KeyConf
String trustStoreAlgorithm = SETTINGS_PARSER.truststoreAlgorithm.get(settings);
SecureString trustStorePassword = SETTINGS_PARSER.truststorePassword.get(settings);
return new StoreTrustConfig(trustStorePath, trustStoreType, trustStorePassword, trustStoreAlgorithm);
} else if (global == null && System.getProperty("javax.net.ssl.trustStore") != null
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@@ -123,19 +123,20 @@ public void testReadIdpMetadataFromHttps() throws Exception {
final Path path = getDataPath("idp1.xml");
final String body = new String(Files.readAllBytes(path), StandardCharsets.UTF_8);
final MockSecureSettings mockSecureSettings = new MockSecureSettings();
mockSecureSettings.setString("xpack.ssl.secure_key_passphrase", "testnode");
mockSecureSettings.setString("xpack.security.transport.ssl.secure_key_passphrase", "testnode");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't really affect anything but we could use xpack.security.http key since the produced SSLContext is used in a MockWebServer

if (value == null) {
try {
if (key.startsWith("xpack.security.transport.ssl.")) {
byte[] file = Streams.readAll(secureSettings.getFile(key));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe move toBytesArray to ESTestCase and use this instead so that we don't introduce BC dependencies again?

Settings settings2 = Settings.builder()
.put("xpack.ssl.key", keyPath)
.put("xpack.ssl.certificate", certPath)
.put("xpack.security.transport.ssl.key", keyPath)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same as above, just for being easy to the eye use the http layer settings for the MockWebServer

try (HttpClient client = new HttpClient(settings, new SSLService(settings, environment), null)) {
MockSecureSettings secureSettings = new MockSecureSettings();
// We can't use the client created above for the server since it only defines a truststore
secureSettings.setString("xpack.ssl.secure_key_passphrase", "testnode-no-subjaltname");
secureSettings.setString("xpack.security.transport.ssl.secure_key_passphrase", "testnode-no-subjaltname");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same as above, just for being easy to the eye use the http layer settings for the MockWebServer

Copy link
Contributor

@tvernum tvernum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.
It looks like it was a massive effort to work through all those tests.

@jaymode
Copy link
Member Author

jaymode commented Jan 11, 2019

It looks like it was a massive effort to work through all those tests.

Yes it was. So much that merging 6+ months worth of changes was better than starting fresh.

@jaymode
Copy link
Member Author

jaymode commented Jan 14, 2019

run gradle build tests 1

@jaymode jaymode merged commit f3edbe2 into elastic:master Jan 14, 2019
@jaymode jaymode deleted the no_ssl_fallback branch January 14, 2019 21:06
jasontedor added a commit to jasontedor/elasticsearch that referenced this pull request Jan 15, 2019
* master: (28 commits)
  Introduce retention lease serialization (elastic#37447)
  Update Delete Watch to allow unknown fields (elastic#37435)
  Make finalize step of recovery source non-blocking (elastic#37388)
  Update the default for include_type_name to false. (elastic#37285)
  Security: remove SSL settings fallback (elastic#36846)
  Adding mapping for hostname field (elastic#37288)
  Relax assertSameDocIdsOnShards assertion
  Reduce recovery time with compress or secure transport (elastic#36981)
  Implement ccr file restore (elastic#37130)
  Fix Eclipse specific compilation issue (elastic#37419)
  Performance fix. Reduce deprecation calls for the same bulk request (elastic#37415)
  [ML] Use String rep of Version in map for serialisation (elastic#37416)
  Cleanup Deadcode in Rest Tests (elastic#37418)
  Mute IndexShardRetentionLeaseTests.testCommit elastic#37420
  unmuted test
  Remove unused index store in directory service
  Improve CloseWhileRelocatingShardsIT (elastic#37348)
  Fix ClusterBlock serialization and Close Index API logic after backport to 6.x (elastic#37360)
  Update the scroll example in the docs (elastic#37394)
  Update analysis.asciidoc (elastic#37404)
  ...
dliappis added a commit to dliappis/rally-teams that referenced this pull request Jan 16, 2019
Update the security configuration with the changes brought in
elastic/elasticsearch#36846
dliappis added a commit to elastic/rally-teams that referenced this pull request Jan 16, 2019
Update the security configuration with the changes brought in
elastic/elasticsearch#36846

Relates #12
@jimczi jimczi added v7.0.0-beta1 and removed v7.0.0 labels Feb 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants