Hi Valentin, after discussing this offline with Rajini we concluded that your solution for the JVM will work fine and there is no further correlation required between librdkafka and Java clients on this issue.
Thanks, Magnus 2018-05-23 17:32 GMT+02:00 Valentín Gutierrez <vgutier...@wikimedia.org>: > Hi, > > At the Wikimedia Foundation (WMF) we are currently conducting a > security review regarding TLS on our kafka stack[1]. As part of this > review we identified some gaps regarding TLS customization in > librdkafka and we submitted a PR to the project[2]. The ultimate goal > of the PR is allowing us to avoid even offering insecure algorithms > during the TLS handshake. I.e: avoid the usage of certificate > signature algorithms involving SHA1. > > Magnus Edenhill mentioned in PR[3] some ongoing work/discussion about > keeping librdkafka capabilities inline with the corresponding Java clients. > > We didn't need (yet) a similar PR on the Kafka broker side because we are > able to influence TLS behaviour through System and Security Properties > on the JVM. I.e: the counterpart of ssl.curves.list proposed in [1] is > -Djdk.tls.namedGroups (option added in j8u121). > > I'd like your input in our current approach, if handling TLS > parameters through JVM settings is the way to go or it would be better > to implement the same TLS settings on the Java client and/or Kafka > broker itself. > > Thanks, > Valentín Gutiérrez > > [1] https://phabricator.wikimedia.org/T182993 > [2] https://github.com/edenhill/librdkafka/pull/1809 > [3] https://github.com/edenhill/librdkafka/pull/1809# > pullrequestreview-120982957 >
