-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
base: master
Are you sure you want to change the base?
Add SslOptions #3980
Conversation
inspired by SslVerifyMode in Lettuce
There was a problem hiding this 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 ?
src/main/java/redis/clients/jedis/DefaultJedisClientConfig.java
Outdated
Show resolved
Hide resolved
src/main/java/redis/clients/jedis/DefaultJedisClientConfig.java
Outdated
Show resolved
Hide resolved
@@ -0,0 +1,8 @@ | |||
package redis.clients.jedis; | |||
|
|||
public enum SslHostnameVerifyMode { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
I have the same question. The motivation of the change is important in this case. |
|
There was a problem hiding this 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 |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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)); |
There was a problem hiding this comment.
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?
to avoid confusion at this moment.
does this reduce confusion?
There was a problem hiding this comment.
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;
}
};
There was a problem hiding this comment.
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.
Similar to SslOptions in Lettuce library.