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.
>>
>>

Reply via email to