In other words, Kafka doesn't necessarily need to derive another interface/mechanism to make SSLEngine pluggable. That interface/mechanism exists in Java with Security Provider's SSLContext Algorithms. Ref-1: https://docs.oracle.com/javase/9/docs/specs/security/standard-names.html#sslcontext-algorithms Ref-2: https://github.com/bcgit/bc-java/blob/master/tls/src/main/java/org/bouncycastle/jsse/provider/BouncyCastleJsseProvider.java#L193
About the " whole world chooses to make the javax.net.ssl.SSLSocketFactory pluggable" I found the official documentation reinforcing my point I made above, "The javax.net.ssl.SSLSocket class represents a network socket that encapsulates SSL/TLS support on top of a normal stream socket ( java.net.Socket). Some applications might want to use alternate data transport abstractions (e.g., New-I/O); the javax.net.ssl.SSLEngine class is available to produce and consume SSL/TLS packets." Reference: https://docs.oracle.com/javase/7/docs/technotes/guides/security/overview/jsoverview.html I feel that we have to think about building SSLContext in a pluggable way since that is the class that takes "key/trust" material and secure-random config and help creates SSLEngine, SocketFactories via the TLS algorithm's provider specified by Security Provider configuration. Thanks Maulin On Fri, Oct 4, 2019 at 10:28 AM Maulin Vasavada <maulin.vasav...@gmail.com> wrote: > 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. >> >> >> >> >> >
