Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Vlad Skarzhevskyy
    @skarzhevskyy
    Having configured all REST and WebService connections to use sslcontext-kickstart I see the there some thing can't seem to cover using JAVA api. This are Kafka clients and apache-commons-vfs. They do expect string properties to "ssl.truststore.location" --- commons-vfs is using Apache HttpClient at the end they build sslSocketFactory at the end still possible to customize I think
    Hakky54
    @Hakky54
    I have never tried kafka actually, so i am not really sure about the possibilities. Are you using kafka with spring? If thats the case you might be able to intercept the configuration and inject your custom sslcontext from the sslfactory. But now quite sure of that is possible. I did something similar with spring and tomcat.
    Hakky54
    @Hakky54
    It looks like there is a possibility, see here for the merged pull request: https://github.com/apache/kafka/pull/8338/files
    You can implement the SslEngineFactory interface from Kafka and provide your own SSLEngine from the SSLFactory. So to get the sslEngine you could call: sslFactory.getSslContext.createSSLEngine()
    Vlad Skarzhevskyy
    @skarzhevskyy

    commons-vfs HTTPS connection seems working (using httpcomponents v4)
    `
    public class MyHttp4sFileProviderWithSSL extends org.apache.commons.vfs2.provider.http4.Http4sFileProvider {

    @Override
    protected HttpClientBuilder createHttpClientBuilder(Http4FileSystemConfigBuilder builder, GenericFileName rootName, FileSystemOptions fileSystemOptions)
            throws FileSystemException {
        HttpClientBuilder httpClientBuilder = super.createHttpClientBuilder(builder, rootName, fileSystemOptions);
        if (MyEnvironmentSSL.instance().isSSLActivated()) {
            httpClientBuilder
                    .setRoutePlanner(null)
                    .setConnectionManager(null)
                    .setSSLSocketFactory(Apache4SslUtils.toSocketFactory(MyEnvironmentSSL.instance().getSslFactory()));
        }
        return httpClientBuilder;
    }

    }

    DefaultFileSystemManager fileSystemManager = new DefaultFileSystemManager();
    fileSystemManager.addProvider("https", new MyHttp4sFileProviderWithSSL());
    `
    Will try Kafka now

    Hakky54
    @Hakky54
    That’s great to hear! Also great that you are using the Apache4SslUtils :)
    If it is working for Kafka, I might be able to extend SSLFactory to create a SSLEngine with preconfigured ciphers/protocols from the builder
    Vlad Skarzhevskyy
    @skarzhevskyy

    In fact I'm not using Apache4SslUtils. I just copy pasted the 5 lines to my code here as example to make it simple :) This brings me to the question why you had separated Apache4SslUtils to is own jar .
    You could have used optional scope dependencies in sslcontext-kickstart

            <dependency>
                <groupId>org.apache.httpcomponents</groupId>
                <artifactId>httpclient</artifactId>
                <optional>true</optional>
            </dependency>

    Is this about DIY zero-dependency ?

    Vlad Skarzhevskyy
    @skarzhevskyy
    As to Kafka
    Hakky54
    @Hakky54
    Initially I had the apache, netty and jetty libraries in one single maven module. It also contained google’s library guava and apache commons lang. A developer gave feedback and mentioned the topic dependency hell. After that I decided to make the core library as light as possible so others would not need to pull additional libraries which they maybe wouldn’t use and also the prevent overruling their own dependency version if they have the same transitive dependency. An option would be marking the dependency optional, but that would force the end user to add the specific dependency, netty, jetty, or boucy caste etc to their pom explicitly. I didn’t preferred that, I thought the cleanest solution would be seperating functionality which depends on specific libraries into seperate jars. And if they want to use it they would get all the libraries as transitive dependency
    Hakky54
    @Hakky54
    Thank you for sharing your code snippet, so one way authentication works for kafka right?

    I was very eager to try it out yesterday night, so I ended up coding:

    It looks similar to your solution, but I was not quite sure if it would work without the keystone/truststore in the ssl engine factory. I was thinking that they would not be needed if the engine has the pre initialized key manager and trust manager and if shouldBeRebuilt returns false. But I need to try this with a poc with ssl enabled

    Hakky54
    @Hakky54
    But I am not quite sure if there is any need to provide such a extension to the kafka library