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 SslOptions #3980

Draft
wants to merge 11 commits into
base: master
Choose a base branch
from
Draft

Add SslOptions #3980

wants to merge 11 commits into from

Conversation

sazzad16
Copy link
Collaborator

Similar to SslOptions in Lettuce library.

Copy link
Collaborator

@atakavci atakavci left a comment

Choose a reason for hiding this comment

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

having a trust manager like this smells off. May be its because i am lack of context. What is the rationale ?

@@ -0,0 +1,8 @@
package redis.clients.jedis;

public enum SslHostnameVerifyMode {
Copy link

Choose a reason for hiding this comment

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

This is the equivalent of the SslVerifyMode in Lettuce, correct?

Copy link
Contributor

Choose a reason for hiding this comment

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

It's not an equivalent of the SslVerifyMode in Lettuce, but it should be.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is exactly SslVerifyMode in Lettuce except the NONE option.
All the remaining options are specific to hostname verification.
So I named this as such.

Copy link

Choose a reason for hiding this comment

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

Just to make sure I get this right:

SslVerifyMode.CA == SslHostnameVerifyMode.DISABLE
SslVerifyMode.FULL == SslHostnameVerifyMode.HTTPS

I am a bit confused by the naming. HTTPS is HTTP + SSL, we do not use the HTTP protocol.
Also if we only have two modes perhaps we can just have a Boolean value, and not an enum?
Do we plan to have more? What would they be?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@tishun In Lettuce,

SslVerifyMode.FULL ==> setEndpointIdentificationAlgorithm("HTTPS")
SslVerifyMode.CA ==> setEndpointIdentificationAlgorithm("")

So I opted for those names.
REVERTED, to reduce confusion atm.

Copy link

Choose a reason for hiding this comment

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

I understand. The setEndpointIdentificationAlgorithm uses standard names from the Java specification, but I think they are generic and in this case could be misleading if used as part of the API of the driver. A friendly name could describe better (I do not insist on the same naming as in Lettuce, although similar names could make it easier for a app developers to switch between them).

We could always leave a note in the public JavaDoc that this specific enum value would result in using the HTTPS Endpoint Identification Algorithm (for verbosity).

@tishun
Copy link

tishun commented Oct 1, 2024

having a trust manager like this smells off. May be its because i am lack of context. What is the rationale ?

I have the same question. The motivation of the change is important in this case.

@uglide
Copy link
Contributor

uglide commented Oct 2, 2024

@tishun @atakavci This is an attempt to create a TLS config similar to what we have in Lettuce, as a more developer-friendly option compared to the current approach with SSLSocketFactory, etc.

@sazzad16
Copy link
Collaborator Author

sazzad16 commented Oct 2, 2024

having a trust manager like this smells off. May be its because i am lack of context. What is the rationale ?

I have the same question. The motivation of the change is important in this case.

@tishun

  1. Lettuce has similar support.
  2. Users want insecurity.

Copy link

@tishun tishun left a comment

Choose a reason for hiding this comment

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

I may not be getting the whole idea, so please excuse me if my comments are not making sense.

My current assumption is that we only want to be able to enable and disable hostname verification, as part of the SSL verification process.

@@ -28,6 +30,7 @@ public final class DefaultJedisClientConfig implements JedisClientConfig {

private final boolean readOnlyForRedisClusterReplicas;

// TODO: how many constructors should we have? 1) all params, 2) builder 3) another config
Copy link

Choose a reason for hiding this comment

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

I would go with the builder pattern. It is perfect for such cases as it allows to have defaults and in the same time tweak only the options you want. It could also easily evolve into having profiles (a thing I wanted to discuss in the team) e.g. StandaloneProfile / ClusterProfile / EnterpriseProfile - each having specific configuration options suitable for the specific use case scenario

@@ -0,0 +1,8 @@
package redis.clients.jedis;

public enum SslHostnameVerifyMode {
Copy link

Choose a reason for hiding this comment

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

Just to make sure I get this right:

SslVerifyMode.CA == SslHostnameVerifyMode.DISABLE
SslVerifyMode.FULL == SslHostnameVerifyMode.HTTPS

I am a bit confused by the naming. HTTPS is HTTP + SSL, we do not use the HTTP protocol.
Also if we only have two modes perhaps we can just have a Boolean value, and not an enum?
Do we plan to have more? What would they be?

public Builder keystore(File keystore, char[] keystorePassword) {

Objects.requireNonNull(keystore, "Keystore must not be null");
// LettuceAssert.isTrue(keystore.exists(), () -> String.format("Keystore file %s does not exist", truststore));
Copy link

Choose a reason for hiding this comment

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

I assume we still want to add these checks, correct?

Copy link

Choose a reason for hiding this comment

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

I believe all we need from this class is

TrustManager[] trustAllCerts = new TrustManager[]{
new X509TrustManager() {
        @Override
        public void checkClientTrusted(X509Certificate[] chain, String s) {
            if (logger.isDebugEnabled()) {
                logger.debug("Accepting a client certificate: " + chain[0].getSubjectDN());
            }
        }

        @Override
        public void checkServerTrusted(X509Certificate[] chain, String s) {
            if (logger.isDebugEnabled()) {
                logger.debug("Accepting a server certificate: " + chain[0].getSubjectDN());
            }
        }

        @Override
        public X509Certificate[] getAcceptedIssuers() {
            return EMPTY_X509_CERTIFICATES;
        }
    };

Copy link
Collaborator Author

@sazzad16 sazzad16 Oct 14, 2024

Choose a reason for hiding this comment

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

@ggivo The X509TrustManager is wrapped to make it X509ExtendedTrustManager.

Sure we can simplify current PR but just wanted to point out that it's not as simple as you've mentioned.

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.

5 participants