On Sat, 2022-06-11 at 11:24 +0200, Graham Leggett wrote:
> Hi all,
> 
> I am trying to pick apart why jackrabbit is ignoring system
> parameters when using SSL.
> 
> According to the javadocs for
> https://www.javadoc.io/doc/org.apache.httpcomponents/httpclient/4.4/org/apache/http/impl/client/HttpClientBuilder.html
>  "System properties will be taken into account when configuring the
> default implementations when useSystemProperties() method is called
> prior to calling build().”
> 
> The code in jackrabbit looks like this:
> 
> https://github.com/apache/jackrabbit/blob/ed3124e5fe223dada33ce6ddf53bc666063c3f2f/jackrabbit-spi2dav/src/main/java/org/apache/jackrabbit/spi2dav/RepositoryServiceImpl.java#L365
> 
>         // request config
>         RequestConfig requestConfig = RequestConfig.custom().
>                
> setConnectTimeout(connectionOptions.getConnectionTimeoutMs()).
>                
> setConnectionRequestTimeout(connectionOptions.getRequestTimeoutMs()).
>                
> setSocketTimeout(connectionOptions.getSocketTimeoutMs()).build();
>         hcb.setDefaultRequestConfig(requestConfig);
>         if
> (Boolean.getBoolean("jackrabbit.client.useSystemProperties") ||
> connectionOptions.isUseSystemPropertes()) {
>             log.debug("Using system properties for establishing
> connection!");
>             // support Java system proxy? (JCR-3211)
>             hcb.useSystemProperties();
>         }
> 
> In theory, the above should cause (when properly config’ed) system
> properties to be used.
> 
> We then do this:
> 
>         // TLS settings (via connection manager)
>         final SSLContext sslContext;
>         try {
>             if (connectionOptions.isAllowSelfSignedCertificates()) {
>                 log.warn("Nonsecure TLS setting: Accepting self-
> signed certificates!");
>                     sslContext =
> SSLContextBuilder.create().loadTrustMaterial(new
> TrustSelfSignedStrategy()).build();
>                     hcb.setSSLContext(sslContext);
> 
> Am I right in understanding that the above will override the system
> properties and create an SSL context that contains no key material
> from system properties?

No, you are not. HttpClient will trust certificates with a single self-
signed certificate in the cert chain but all other certificates (with
two or more signators in the cert chain) will still be verified by the
default trust manager.

> 
>             } else {
>                 sslContext = SSLContextBuilder.create().build();
> 
> Am I also correct in understanding that
> SSLContextBuilder.create().build() above will create a context with
> no key material, ignoring the system properties?
> 

You are correct. However, trust material shipped with the JRE will be
loaded by default (this is not by design, this is how Oracle JSSE
provider behaves). That is, standard CAs will be trusted by default.

>             }
>         } catch (KeyManagementException | NoSuchAlgorithmException |
> KeyStoreException e) {
>             throw new RepositoryException(e);
>         }
>         final SSLConnectionSocketFactory sslSocketFactory;
>         if (connectionOptions.isDisableHostnameVerification()) {
>             log.warn("Nonsecure TLS setting: Host name verification
> of TLS certificates disabled!");
>             // we can optionally disable hostname verification.
>             sslSocketFactory = new
> SSLConnectionSocketFactory(sslContext,
> NoopHostnameVerifier.INSTANCE);
>         } else {
>             sslSocketFactory = new
> SSLConnectionSocketFactory(sslContext);
>         }
>         
>         Registry<ConnectionSocketFactory> socketFactoryRegistry =
> RegistryBuilder.<ConnectionSocketFactory>create()
>             .register("http",
> PlainConnectionSocketFactory.getSocketFactory())
>             .register("https", sslSocketFactory)
>             .build();
> 
> I am trying to work out what changes I need to be above code to make
> this support system properties by default, and then apply changes to
> the system defaults where coded to do so.
> 
> Regards,
> Graham
> —
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to