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

Add deprecation warnings for ssl config fallback #36847

Merged
merged 20 commits into from
Jan 14, 2019

Conversation

jaymode
Copy link
Member

@jaymode jaymode commented Dec 19, 2018

SSL configuration fallback has long been present in security but is a
source of confusion due to the behavior. Ultimately, we plan to remove
support for fallback in the next major version so this commit provides
deprecation warnings for the current line of stable releases.

Relates #36846

SSL configuration fallback has long been present in security but is a
source of confusion due to the behavior. Ultimately, we plan to remove
support for fallback in the next major version so this commit provides
deprecation warnings for the current line of stable releases.
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security

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.

Will there be a follow up PR for the docs that explains why these are deprecated?

@@ -96,7 +97,8 @@

private static final Function<String, Setting<SecureString>> TRUSTSTORE_PASSWORD_TEMPLATE = key ->
SecureSetting.secureString(key, LEGACY_TRUSTSTORE_PASSWORD_TEMPLATE.apply(key.replace("truststore.secure_password",
"truststore.password")));
"truststore.password")),
key.startsWith(XPackSettings.GLOBAL_SSL_PREFIX) ? new Property[] { Property.Deprecated } : new Property[0]);
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't the legacy (non-secure) password always be deprecated? It looks like this just got missed/lost at some point.

Copy link
Member Author

Choose a reason for hiding this comment

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

It is deprecated always. What you are seeing is the fallback setting being configured, which has its own properties; the properties here are the ones for the secure setting.

Copy link
Contributor

Choose a reason for hiding this comment

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

Of course. It really is a bit of a mess isn't it.

List<String> urls = realm.getAsList("url");
if (urls.isEmpty() == false && urls.stream().anyMatch(s -> s.startsWith("ldaps://"))) {
return true;
}
Copy link
Contributor

Choose a reason for hiding this comment

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


static final Function<String, Setting<SecureString>> LEGACY_KEYSTORE_KEY_PASSWORD_TEMPLATE = key -> new Setting<>(key, "",
SecureString::new, Setting.Property.Deprecated, Setting.Property.Filtered, Setting.Property.NodeScope);
static final Function<String, Setting<SecureString>> KEYSTORE_KEY_PASSWORD_TEMPLATE = key ->
SecureSetting.secureString(key, LEGACY_KEYSTORE_KEY_PASSWORD_TEMPLATE.apply(key.replace("keystore.secure_key_password",
"keystore.key_password")));
"keystore.key_password")),
key.startsWith(XPackSettings.GLOBAL_SSL_PREFIX) ? new Property[] { Property.Deprecated } : new Property[0]);
Copy link
Contributor

Choose a reason for hiding this comment

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

Per previous comment, we can probably make this deprecated in all cases.

Copy link
Member Author

Choose a reason for hiding this comment

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

This property is for the secure setting and not the legacy value

SecureSetting.secureString(key, LEGACY_KEY_PASSWORD_TEMPLATE.apply(key.replace("secure_key_passphrase",
"key_passphrase")));
SecureSetting.secureString(key, LEGACY_KEY_PASSWORD_TEMPLATE.apply(key.replace("secure_key_passphrase", "key_passphrase")),
key.startsWith(XPackSettings.GLOBAL_SSL_PREFIX) ? new Property[] { Property.Deprecated } : new Property[0]);
Copy link
Contributor

Choose a reason for hiding this comment

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

As above.

Copy link
Member Author

Choose a reason for hiding this comment

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

This property is for the secure setting and not the legacy value

@jaymode
Copy link
Member Author

jaymode commented Jan 7, 2019

@tvernum I updated docs and added deprecation checks

@jaymode
Copy link
Member Author

jaymode commented Jan 9, 2019

run gradle build tests 1

@jaymode jaymode requested a review from tvernum January 9, 2019 21:21
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

Copy link
Member

@jkakavas jkakavas left a comment

Choose a reason for hiding this comment

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

LGTM, a couple of minor suggestions

return false;
}

private void checkSSLConfigurationForFallback(String name, Settings settings, SSLConfiguration config) {
Copy link
Member

Choose a reason for hiding this comment

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

I think it might be nice to print the key missing from the actual config that falls back to the default value here instead of a descriptive name, but I'm not sure if it can be reliably computed and if it would actually make the deprecation log better, so I just bring it up for consideration

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 agree that it would be nice, but I think the effort to compute this would probably outweigh the benefits

@@ -115,7 +117,7 @@ public void testThatConnectionToServerTypeConnectionWorks() throws IOException,
"/org/elasticsearch/xpack/security/transport/ssl/certs/simple/testnode.pem",
"testnode",
"/org/elasticsearch/xpack/security/transport/ssl/certs/simple/testnode.crt",
Arrays.asList("/org/elasticsearch/xpack/security/transport/ssl/certs/simple/testnode.crt"));
Collections.singletonList("/org/elasticsearch/xpack/security/transport/ssl/certs/simple/testnode.crt"));
Copy link
Member

Choose a reason for hiding this comment

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

👍 thanks for fixing these also

jkakavas and others added 2 commits January 10, 2019 09:29
Co-Authored-By: jaymode <jaymode@users.noreply.github.com>
@jaymode
Copy link
Member Author

jaymode commented Jan 10, 2019

run gradle build tests 2

Tests with failures:

  • org.elasticsearch.upgrades.WatchBackwardsCompatibilityIT.testWatcherRestart

@jaymode
Copy link
Member Author

jaymode commented Jan 10, 2019

run gradle build tests 2

@jaymode jaymode merged commit 680d3b3 into elastic:6.x Jan 14, 2019
@jaymode jaymode deleted the deprecate_ssl_fallback branch January 14, 2019 16:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants