Hi Clement The explanation about using Java Security Providers if you want to use customize SSLEngine is - similar to BouncyCastleJsseProvider we can have a provider that registers SSLContext+(TLS/SSL) services and have implementation for SSLContextSpi which provides various methods to get/create different kind of objects offered by the specific TLS implementation - example: SSLEngine, ServerSocketFactory, SocketFactory. SSLContext works as kind of a "bridge" pattern that once we get SSLContext for a specific protocol (TLSv1.1,TLSv1.2 etc) then ssl engine, socket factory everything is for that protocol implementation.
About the SSLContext vs SSLEngine, I debated the exact point you raise in my mind and I came to the conclusion that - The implementation of Kafka or HTTPs protocol (like ApacheHttpClient) ultimately relies on Java IO/NIO packages and uses some kind of Channel (example: https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/network/TransportLayer.java). Now they have a choice to either use SSLEngine or SSLSocket. It is entirely upto the protocol's implementation to decide that. Hence we can't say everybody must use SSLSocketFacotry vs SSLEngine. I will dig into Apache Http Client and find how they are using SocketFactory. Thanks Maulin On Fri, Oct 4, 2019 at 8:37 AM Pellerin, Clement <clement_pelle...@ibi.com> wrote: > 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. > >> > >> >
