cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Brown (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-13259) Use platform specific X.509 default algorithm
Date Sat, 11 Mar 2017 02:50:04 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-13259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15905828#comment-15905828
] 

Jason Brown edited comment on CASSANDRA-13259 at 3/11/17 2:49 AM:
------------------------------------------------------------------

wrt {{store_type}}, can java8 correctly figure out the difference between a PKCS12 and JKS?
Further, what if somebody went bananas and used a JCEKS (I'm not totally sure this case applies
to TLS)? I agree with you that one declared {{store_type}} is not correct for all situations
(covering both the key and trust stores), but that leads us logically to having a separate
{{store_type}} config option for both keystore and truststore. The {{javax.net.ssl.*}} allow
a differentiation of the store types, but see next paragraph.

wrt JVM-based properties ({{javax.net.ssl.*}}), we currently allow users to have a different
configuration for client-server and internode (peero-to-peer) communications. By removing
both options in favor of using the JVM-based properties, operators who previously had separate
configs are now forced to use the same config for both, and I'm not sure how big of a breakage
that is (in terms of the actual number of opertators/clusters affected).

Also, I spoke with one of the netty developers, and they ignore the {{javax.net.ssl.*}} properties.
Thus I don't think the JVM-based properties is the way to go.

UPDATE: We could *still* use the {{javax.net.ssl.*}} properties, but we would need to plumb
them through ourselves to netty. So perhaps there's an advantage for the the operator (using
the properties is "consistent" with JVM conventions), but we incur a larger cost of supporting
those options and correctly translating those to netty-land.



was (Author: jasobrown):
wrt {{store_type}}, can java8 correctly figure out the difference between a PKCS12 and JKS?
Further, what if somebody went bananas and used a JCEKS (I'm not totally sure this case applies
to TLS)? I agree with you that one declared {{store_type}} is not correct for all situations
(covering both the key and trust stores), but that leads us logically to having a separate
{{store_type}} config option for both keystore and truststore. The {{javax.net.ssl.*}} allow
a differentiation of the store types, but see next paragraph.

wrt JVM-based properties ({{javax.net.ssl.*}}), we currently allow users to have a different
configuration for client-server and internode (peero-to-peer) communications. By removing
both options in favor of using the JVM-based properties, operators who previously had separate
configs are now forced to use the same config for both, and I'm not sure how big of a breakage
that is (in terms of the actual number of opertators/clusters affected).

Also, I spoke with one of the netty developers, and they ignore the {{javax.net.ssl.*}} properties.
Thus I don't think the JVM-based properties is the way to go.


> Use platform specific X.509 default algorithm
> ---------------------------------------------
>
>                 Key: CASSANDRA-13259
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13259
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Configuration
>            Reporter: Stefan Podkowinski
>            Assignee: Stefan Podkowinski
>            Priority: Minor
>             Fix For: 4.x
>
>
> We should replace the hardcoded "SunX509" default algorithm and use the JRE default instead.
This implementation will currently not work on less popular platforms (e.g. IBM) and won't
get any further updates.
> See also:
> https://bugs.openjdk.java.net/browse/JDK-8169745



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message