I am happy to see I am not the only one with reservations on the direction we were heading.
>> I feel if you want to plug any JSSE compatible SSLEngine >> (example BouncyCastle, wildfly-OpenSSL etc) then we have to follow path of >> using Java security provider I like the conclusion but I did not understand your explanation. >> What should be pluggable - SSLContext or SSLEngine? I can only remark that the whole world chooses to make the javax.net.ssl.SSLSocketFactory pluggable. You can find projects making the SSLContext pluggable but I have never seen a project that makes the SSLEngine pluggable. The stumbling blocks in our case are the client/server mode customization and the reusability of the reconfiguration checks. We can always compromise on the reusability of the reconfiguration checks. On the other hand, we really have to learn more about the client/server mode customization because that's unavoidable at the moment. -----Original Message----- From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com] Sent: Friday, October 4, 2019 4:13 AM To: dev@kafka.apache.org Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration extensible Hi all I've been having more thoughts on SSLEngine vs SSLContext pluggability (reasons for hiatus from my side until now). Based on my further research and understanding, various TLS implementations https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations , makes it clear that there are implementations that may not be originally complying to JSSE BUT they eventually might provide JSSE Provider, example - BouncyCastleJsseProvider - https://github.com/bcgit/bc-java/blob/master/tls/src/main/java/org/bouncycastle/jsse/provider/BouncyCastleJsseProvider.java. In those cases, I feel if you want to plug any JSSE compatible SSLEngine (example BouncyCastle, wildfly-OpenSSL etc) then we have to follow path of using Java security provider (like using BouncyCastleJsseProvider class). We can't easily just use the proposed SslEngineFactory interface. Also, the existing logic of createEngine() method actually just does sslContext.createEngine() and then customize the object further based on the Client/Server mode. It doesn't really do any customization of SSLEngine wrap/unwrap methods which are the heart of it. That urges me to think more that actually we need SSLContext to be pluggable. Either way, point of discussions about reconfigurability and questions Clement asked remains similar BUT I think we might have to first really resolve "What should be pluggable - SSLContext or SSLEngine?" question. Let me know your thoughts! Thanks Maulin On Wed, Sep 25, 2019 at 10:56 PM Maulin Vasavada <maulin.vasav...@gmail.com> wrote: > Ack. I should be able to get back to this on Friday. > > On Mon, Sep 23, 2019 at 10:35 AM Pellerin, Clement < > clement_pelle...@ibi.com> wrote: > >> When I worked on KIP-383 I was told the way to pass extra arguments to an >> instance is to add extra arguments to configure. I would now suggest we do >> like the KeySerializer. If you look in KafkaProducer, it creates a >> KeySerializer using AbstractConfig. getConfiguredInstance(). Since >> KeySerializer does not extend KeySerializer, AbstractConfig does not call >> configure(Map). KafkaProducer then calls configure() with two arguments. >> This removes the need for the init() method which would be called too late >> after configure(). By the way, the KeySerializer is not the only interface >> that does this. >> >> In summary, SslEngineFactory does not extend Configurable and it has a >> configure() method with more than 1 argument. >> >> The next item is to spec how config.originals() is passed to >> SslChannelBuilder: the KIP needs to explain we will push the choice of >> configs within the switch in ChannelBuilders.create() >> >> Finally, we need to spec which configs are passed to shouldRebuiltFor(). >> I assume these are now originals() instead of values(). We also need to >> specify if all configs are passed or just the reconfigurable ones. >> >>
