bump! On Sun, Oct 13, 2019 at 11:16 PM Maulin Vasavada <maulin.vasav...@gmail.com> wrote:
> Hi Clement > > 1) existing validation code will remain in SslFactory > 2) the createEngine() method in SslEngineBuilder will move to SslFactory > and the client/server mode setting will go there (I documented this in the > latest KIP update) > > In the current KIP I am proposing (as per the latest updates) to make > SSLContext loading/configuration/creation pluggable. I am not suggesting we > do/repeat anything that is already addressed by the existing Providers for > SSLContext implementation. The createEngine() method (which will move to > SslFactory) will call SslContextFactory.create() to get references to the > SSLContext and then call SSLContext#createEngine(peer, host) and set > client/server mode as it does today. I'll try to put that in a sequence > diagram and update the KIP to make it clearer. > > So to your question about SslFactory returning SSLContext - I am saying > register SslContextFactory interface to provide the SSLContext object > instead and keep SslFactory more-or-less as it is today with some > additional responsibility of createEngine() method. > > Thanks > Maulin > > Thanks > Maulin > > > > > On Fri, Oct 11, 2019 at 6:17 AM Pellerin, Clement < > clement_pelle...@ibi.com> wrote: > >> Can you clarify a few points for me? >> >> The two stumbling blocks we have are: >> 1) reuse of the validation code in the existing SslFactory >> 2) the client/server mode on the SSLEngine >> >> How do you deal with those issues in your new proposal? >> >> My use case is to register a custom SslFactory that returns an SSLContext >> previously created elsewhere in the application. Can your new proposal >> handle this use case? >> >> -----Original Message----- >> From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com] >> Sent: Friday, October 11, 2019 2:13 AM >> To: dev@kafka.apache.org >> Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration >> extensible >> >> Check this out- >> >> https://github.com/apache/httpcomponents-core/blob/master/httpcore5/src/main/java/org/apache/hc/core5/ssl/SSLContextBuilder.java#L349 >> >> This is exactly what I mean by using existing provider's SSLContext >> implementation and customizing it with our data points. The similar thing >> Kafka's SslEngineBuilder is doing right now. >> >> On Thu, Oct 10, 2019 at 11:06 PM Maulin Vasavada < >> maulin.vasav...@gmail.com> >> wrote: >> >> > You meant JSSE not JCE right? We are not talking about cryptographic >> > providers we are talking about ssl providers hence JSSE. >> > >> > I do understand how JSSE Providers work and also the impact of multiple >> > JSSE providers with same algorithms in same JVM along with sequencing >> > challenges for the same. >> > >> > Like you said- we need to allow customizing the configuration for >> > SSLContext, so how many ways we have? >> > >> > Option-1: Write a custom JSSE Provider with our SSLContext >> > >> > Option-2: Use whichever SSLContext impl that you get from existing JSSE >> > Provider for SSLContext AND customize data for key material, trust >> material >> > AND secure random. >> > >> > Which one you prefer for this context? >> > >> > I feel we are making it complicated for no reason. It is very simple - >> > When we need to have SSL we need data points like - 1) Keys, 2) Trust >> certs >> > and 3) Secure Random which is feed to SSLContext and we are done. So we >> can >> > keep existing Kafka implementation as is by just making those data >> points >> > pluggable. Now SecureRandom is already pluggable via >> > 'ssl.secure.random.implementation' so that leaves us with keys and >> trusted >> > certs. For that purpose I raised KIP-486 BUT everybody feels we still >> need >> > higher level of pluggability hence this KIP. >> > >> > I"ve been taking advice from the domain experts and Application security >> > teams and to them it is very straight-forward - Make SSLContext >> > configuration/building pluggable and that's it! >> > >> > Thanks >> > Maulin >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > On Mon, Oct 7, 2019 at 5:47 AM Pellerin, Clement < >> clement_pelle...@ibi.com> >> > wrote: >> > >> >> If I understand correctly, you are proposing to abandon the idea of a >> >> pluggable extension point for SSL in Kafka because we could rely on >> the JCE >> >> provider mechanism. >> >> >> >> I will reiterate that nobody does it that way. That in itself should be >> >> enough but let's discuss some of the reasons why. >> >> >> >> Changing the order of the JCE providers in the java.security file >> affects >> >> all java applications so you probably don't want to do it there. >> Changing >> >> the order of the JCE providers in the JVM instance affects all code it >> >> runs. Your library is not alone in the JVM process and other code will >> want >> >> regular SSLContext instances. That leaves you with the only option of >> >> specifying the provider explicitly when you create the SSLContext >> instance >> >> in Kafka. That would work, as long as your users don't mess things up >> with >> >> the very common configuration approaches above. >> >> >> >> A JCE SSLContext provider is intended to be a mechanism to replace the >> >> SSLContext implementation. Our purpose is to customize the >> configuration, >> >> not to replace it. This becomes hard to do when your only chance is at >> >> creation time. Kafka then does its thing and you have no way to modify >> that >> >> behavior in Kafka. You no longer support many legitimate use cases. >> >> >> >> The final blow is the need to sign JCE providers using a certificate >> >> signed by Oracle's JCE Code Signing Certification Authority. >> >> >> >> >> https://www.oracle.com/technetwork/java/javase/tech/getcodesigningcertificate-361306.html >> >> JCE will refuse to load your provider if it is not signed. Getting the >> >> certificate is a pain and it takes time. You also have to worry about >> the >> >> certificate expiration date. There are JVMs that don't require signed >> JCE >> >> providers, but you cannot limit Kafka to just those JVMs. >> >> >> >> -----Original Message----- >> >> From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com] >> >> Sent: Friday, October 4, 2019 5:31 PM >> >> To: dev@kafka.apache.org >> >> Subject: Re: [DISCUSS] KIP-519: Make SSL context/engine configuration >> >> extensible >> >> >> >> 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://docs.oracle.com/javase/9/docs/specs/security/standard-names.html#sslcontext-algorithmsRef-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 >> >> >> >> >> >
