Re: JClouds TLS SNI support?

[Ignasi Barrera]

Better open one issue with all the details you got. Thanks!

On 15 September 2016 at 12:20, cen  wrote:
> Sure. Should I open the issue specifically about Apache client and another
> one for default Java client?
>
> The unexplained thing is why the default Java client isn't working with SNI
> by default, even though it should in theory (Java 8 sends SNI automatically
> and by default according to Oracle docs). The closest thing I found is this:
> http://stackoverflow.com/questions/30817934/extended-server-name-sni-extension-not-sent-with-jdk1-8-0-but-send-with-jdk1-7
> a possible OpenJDK bug.
>
> A quick dig into JClouds code seems to confirm that setHostnameVerifier() is
> used so this could be the case.
>
>
> Ignasi Barrera je 15. 09. 2016 ob 12:06 napisal:
>
>> Thanks for the feedback and all the details cen!
>>
>> Would you mind opening an issue in our JIRA so we can track and fix
>> the Apache driver?
>>
>>
>>
>> On 15 September 2016 at 11:17, cen  wrote:
>>>
>>> Hi
>>>
>>> Default driver and Apache driver failed me but OkHTTP worked.
>>>
>>> For Apache, I found a similar bug in Keycloak JIRA:
>>> https://issues.jboss.org/browse/KEYCLOAK-2439
>>>
>>> The interesting part is:
>>>
>>> "Client adapter uses a deprecated API when setting up HttpClient object
>>> in
>>> org.keycloak.adapters.HttpClientBuilder. As a result, a SNI patch which
>>> is
>>> part of HttpClient library since version 4.3.2, and which seems to
>>> delegate
>>> this part to Java SDK classes, where SNI is automatically set, isn't
>>> activated."
>>>
>>> It's a guess on my part but I assume JClouds instantiates the HttpClient
>>> in
>>> a way that SNI does not get activated.
>>>
>>> I digged more into Apache driver and the way SSLSocketFactory is used by
>>> JClouds is very similar to pre-patched Keycloak from that Jira issue
>>> (according to pull requests). Might be worth looking into.
>>>
>>> Best regards, cen
>>>
>>>
>>> Ignasi Barrera je 12. 09. 2016 ob 21:04 napisal:
>>>
>>> Hi!
>>>
>>> jclouds supports several HTTP drivers. By default it relies on the java
>>> HttpUrlConection, but you can also configure it to use the Apache Http
>>> client or OkHttp [1]. Using those drivers is as simple as adding the
>>> corresponding Guice module when creating the context (have a look at the
>>> OkHttp driver readme for an example [2]) so feel free to use the one that
>>> is better for your use case.
>>>
>>> If you need more control on how the http client is configured, you can
>>> take
>>> the jclouds Docker api as an example. It configures the OkHttp to support
>>> TLS connections. You can have a look at its docker http module [3] and
>>> create a similar module that initializes the OkHtttpClient as needed, and
>>> then pass it to the ContextBuilder when creating the jclouds context.
>>>
>>> HTH!
>>>
>>> I.
>>>
>>> [1] https://github.com/jclouds/jclouds/tree/master/drivers
>>> [2]
>>> https://github.com/jclouds/jclouds/blob/master/drivers/okhttp/README.md
>>> [3]
>>>
>>> https://github.com/jclouds/jclouds/blob/master/apis/docker/src/main/java/org/jclouds/docker/config/DockerHttpApiModule.java
>>>
>>> El 12 sept. 2016 7:02 p. m., "cen"  escribió:
>>>
>>> Hi
>>>
>>> We have a FakeS3 instance behind a reverse proxy which handles several
>>> subdomains over a single IP. We use let's encrypt certificate to sign the
>>> subdomains. We have the latest Java 8 installed which has the let's
>>> encrypt
>>> root in it's truststore. However, JClouds fails to connect to our FakeS3
>>> instance over https (http works). We believe it is because TLS SNI is not
>>> supported in JClouds since this is the most common problem we found other
>>> people having when googling around. I browsed around org.jclouds.http
>>> package but I was unable to determine what HTTP client does JClouds use
>>> behind the scenes or if it's a custom implementation. Could I get some
>>> feedback whether my assumptions are correct and how hard would it be to
>>> fix
>>> this? This is the stacktrace:
>>>
>>>
>>> PKIX path building failed:
>>> sun.security.provider.certpath.SunCertPathBuilderException:
>>> unable to find valid certification path to requested target connecting to
>>> HEAD https://s3.demo.mydomain.com/productname HTTP/1.1
>>>  at org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(
>>> BaseHttpCommandExecutorService.java:121)
>>>  at org.jclouds.rest.internal.InvokeHttpMethod.invoke(
>>> InvokeHttpMethod.java:90)
>>>  at org.jclouds.rest.internal.InvokeHttpMethod.apply(
>>> InvokeHttpMethod.java:73)
>>>  at org.jclouds.rest.internal.InvokeHttpMethod.apply(
>>> InvokeHttpMethod.java:44)
>>>  at org.jclouds.rest.internal.DelegatesToInvocationFunction.handle(
>>> DelegatesToInvocationFunction.java:156)
>>>  at org.jclouds.rest.internal.DelegatesToInvocationFunction.invoke(
>>> DelegatesToInvocationFunction.java:123)
>>>  at com.sun.proxy.$Proxy146.bucketExists(Unknown Source)

Re: JClouds TLS SNI support?

[cen]

Sure. Should I open the issue specifically about Apache client and 
another one for default Java client?


The unexplained thing is why the default Java client isn't working with 
SNI by default, even though it should in theory (Java 8 sends SNI 
automatically and by default according to Oracle docs). The closest 
thing I found is this: 
http://stackoverflow.com/questions/30817934/extended-server-name-sni-extension-not-sent-with-jdk1-8-0-but-send-with-jdk1-7 
a possible OpenJDK bug.


A quick dig into JClouds code seems to confirm that 
setHostnameVerifier() is used so this could be the case.



Ignasi Barrera je 15. 09. 2016 ob 12:06 napisal:

Thanks for the feedback and all the details cen!

Would you mind opening an issue in our JIRA so we can track and fix
the Apache driver?



On 15 September 2016 at 11:17, cen  wrote:

Hi

Default driver and Apache driver failed me but OkHTTP worked.

For Apache, I found a similar bug in Keycloak JIRA:
https://issues.jboss.org/browse/KEYCLOAK-2439

The interesting part is:

"Client adapter uses a deprecated API when setting up HttpClient object in
org.keycloak.adapters.HttpClientBuilder. As a result, a SNI patch which is
part of HttpClient library since version 4.3.2, and which seems to delegate
this part to Java SDK classes, where SNI is automatically set, isn't
activated."

It's a guess on my part but I assume JClouds instantiates the HttpClient in
a way that SNI does not get activated.

I digged more into Apache driver and the way SSLSocketFactory is used by
JClouds is very similar to pre-patched Keycloak from that Jira issue
(according to pull requests). Might be worth looking into.

Best regards, cen


Ignasi Barrera je 12. 09. 2016 ob 21:04 napisal:

Hi!

jclouds supports several HTTP drivers. By default it relies on the java
HttpUrlConection, but you can also configure it to use the Apache Http
client or OkHttp [1]. Using those drivers is as simple as adding the
corresponding Guice module when creating the context (have a look at the
OkHttp driver readme for an example [2]) so feel free to use the one that
is better for your use case.

If you need more control on how the http client is configured, you can take
the jclouds Docker api as an example. It configures the OkHttp to support
TLS connections. You can have a look at its docker http module [3] and
create a similar module that initializes the OkHtttpClient as needed, and
then pass it to the ContextBuilder when creating the jclouds context.

HTH!

I.

[1] https://github.com/jclouds/jclouds/tree/master/drivers
[2] https://github.com/jclouds/jclouds/blob/master/drivers/okhttp/README.md
[3]
https://github.com/jclouds/jclouds/blob/master/apis/docker/src/main/java/org/jclouds/docker/config/DockerHttpApiModule.java

El 12 sept. 2016 7:02 p. m., "cen"  escribió:

Hi

We have a FakeS3 instance behind a reverse proxy which handles several
subdomains over a single IP. We use let's encrypt certificate to sign the
subdomains. We have the latest Java 8 installed which has the let's encrypt
root in it's truststore. However, JClouds fails to connect to our FakeS3
instance over https (http works). We believe it is because TLS SNI is not
supported in JClouds since this is the most common problem we found other
people having when googling around. I browsed around org.jclouds.http
package but I was unable to determine what HTTP client does JClouds use
behind the scenes or if it's a custom implementation. Could I get some
feedback whether my assumptions are correct and how hard would it be to fix
this? This is the stacktrace:


PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target connecting to
HEAD https://s3.demo.mydomain.com/productname HTTP/1.1
 at org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(
BaseHttpCommandExecutorService.java:121)
 at org.jclouds.rest.internal.InvokeHttpMethod.invoke(
InvokeHttpMethod.java:90)
 at org.jclouds.rest.internal.InvokeHttpMethod.apply(
InvokeHttpMethod.java:73)
 at org.jclouds.rest.internal.InvokeHttpMethod.apply(
InvokeHttpMethod.java:44)
 at org.jclouds.rest.internal.DelegatesToInvocationFunction.handle(
DelegatesToInvocationFunction.java:156)
 at org.jclouds.rest.internal.DelegatesToInvocationFunction.invoke(
DelegatesToInvocationFunction.java:123)
 at com.sun.proxy.$Proxy146.bucketExists(Unknown Source)
 at org.jclouds.s3.blobstore.S3BlobStore.containerExists(
S3BlobStore.java:131)
 at com.redacted.util.storage.S3Storage.saveBlob(S3Storage.java:42)
 at com.redacted.util.storage.BlobStorageImpl.saveBlob(
BlobStorageImpl.java:19)
 at com.redacted.api.rest.v1.resources.ImagesResourceImpl.createTenant(
ImagesResourceImpl.java:90)
 at com.redacted.api.rest.v1.resources.ImagesResourceImpl$
Proxy$_$$_WeldSubclass.createTenant$$super(Unknown Source)
 at 

Re: JClouds TLS SNI support?

[Ignasi Barrera]

Thanks for the feedback and all the details cen!

Would you mind opening an issue in our JIRA so we can track and fix
the Apache driver?



On 15 September 2016 at 11:17, cen  wrote:
> Hi
>
> Default driver and Apache driver failed me but OkHTTP worked.
>
> For Apache, I found a similar bug in Keycloak JIRA:
> https://issues.jboss.org/browse/KEYCLOAK-2439
>
> The interesting part is:
>
> "Client adapter uses a deprecated API when setting up HttpClient object in
> org.keycloak.adapters.HttpClientBuilder. As a result, a SNI patch which is
> part of HttpClient library since version 4.3.2, and which seems to delegate
> this part to Java SDK classes, where SNI is automatically set, isn't
> activated."
>
> It's a guess on my part but I assume JClouds instantiates the HttpClient in
> a way that SNI does not get activated.
>
> I digged more into Apache driver and the way SSLSocketFactory is used by
> JClouds is very similar to pre-patched Keycloak from that Jira issue
> (according to pull requests). Might be worth looking into.
>
> Best regards, cen
>
>
> Ignasi Barrera je 12. 09. 2016 ob 21:04 napisal:
>
> Hi!
>
> jclouds supports several HTTP drivers. By default it relies on the java
> HttpUrlConection, but you can also configure it to use the Apache Http
> client or OkHttp [1]. Using those drivers is as simple as adding the
> corresponding Guice module when creating the context (have a look at the
> OkHttp driver readme for an example [2]) so feel free to use the one that
> is better for your use case.
>
> If you need more control on how the http client is configured, you can take
> the jclouds Docker api as an example. It configures the OkHttp to support
> TLS connections. You can have a look at its docker http module [3] and
> create a similar module that initializes the OkHtttpClient as needed, and
> then pass it to the ContextBuilder when creating the jclouds context.
>
> HTH!
>
> I.
>
> [1] https://github.com/jclouds/jclouds/tree/master/drivers
> [2] https://github.com/jclouds/jclouds/blob/master/drivers/okhttp/README.md
> [3]
> https://github.com/jclouds/jclouds/blob/master/apis/docker/src/main/java/org/jclouds/docker/config/DockerHttpApiModule.java
>
> El 12 sept. 2016 7:02 p. m., "cen"  escribió:
>
> Hi
>
> We have a FakeS3 instance behind a reverse proxy which handles several
> subdomains over a single IP. We use let's encrypt certificate to sign the
> subdomains. We have the latest Java 8 installed which has the let's encrypt
> root in it's truststore. However, JClouds fails to connect to our FakeS3
> instance over https (http works). We believe it is because TLS SNI is not
> supported in JClouds since this is the most common problem we found other
> people having when googling around. I browsed around org.jclouds.http
> package but I was unable to determine what HTTP client does JClouds use
> behind the scenes or if it's a custom implementation. Could I get some
> feedback whether my assumptions are correct and how hard would it be to fix
> this? This is the stacktrace:
>
>
> PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException:
> unable to find valid certification path to requested target connecting to
> HEAD https://s3.demo.mydomain.com/productname HTTP/1.1
> at org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(
> BaseHttpCommandExecutorService.java:121)
> at org.jclouds.rest.internal.InvokeHttpMethod.invoke(
> InvokeHttpMethod.java:90)
> at org.jclouds.rest.internal.InvokeHttpMethod.apply(
> InvokeHttpMethod.java:73)
> at org.jclouds.rest.internal.InvokeHttpMethod.apply(
> InvokeHttpMethod.java:44)
> at org.jclouds.rest.internal.DelegatesToInvocationFunction.handle(
> DelegatesToInvocationFunction.java:156)
> at org.jclouds.rest.internal.DelegatesToInvocationFunction.invoke(
> DelegatesToInvocationFunction.java:123)
> at com.sun.proxy.$Proxy146.bucketExists(Unknown Source)
> at org.jclouds.s3.blobstore.S3BlobStore.containerExists(
> S3BlobStore.java:131)
> at com.redacted.util.storage.S3Storage.saveBlob(S3Storage.java:42)
> at com.redacted.util.storage.BlobStorageImpl.saveBlob(
> BlobStorageImpl.java:19)
> at com.redacted.api.rest.v1.resources.ImagesResourceImpl.createTenant(
> ImagesResourceImpl.java:90)
> at com.redacted.api.rest.v1.resources.ImagesResourceImpl$
> Proxy$_$$_WeldSubclass.createTenant$$super(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocation
> Context.proceedInternal(TerminalAroundInvokeInvocationContext.java:49)
> at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.
> 

Re: JClouds TLS SNI support?

[Ignasi Barrera]

Hi!

jclouds supports several HTTP drivers. By default it relies on the java
HttpUrlConection, but you can also configure it to use the Apache Http
client or OkHttp [1]. Using those drivers is as simple as adding the
corresponding Guice module when creating the context (have a look at the
OkHttp driver readme for an example [2]) so feel free to use the one that
is better for your use case.

If you need more control on how the http client is configured, you can take
the jclouds Docker api as an example. It configures the OkHttp to support
TLS connections. You can have a look at its docker http module [3] and
create a similar module that initializes the OkHtttpClient as needed, and
then pass it to the ContextBuilder when creating the jclouds context.

HTH!

I.

[1] https://github.com/jclouds/jclouds/tree/master/drivers
[2] https://github.com/jclouds/jclouds/blob/master/drivers/okhttp/README.md
[3]
https://github.com/jclouds/jclouds/blob/master/apis/docker/src/main/java/org/jclouds/docker/config/DockerHttpApiModule.java

El 12 sept. 2016 7:02 p. m., "cen"  escribió:

> Hi
>
> We have a FakeS3 instance behind a reverse proxy which handles several
> subdomains over a single IP. We use let's encrypt certificate to sign the
> subdomains. We have the latest Java 8 installed which has the let's encrypt
> root in it's truststore. However, JClouds fails to connect to our FakeS3
> instance over https (http works). We believe it is because TLS SNI is not
> supported in JClouds since this is the most common problem we found other
> people having when googling around. I browsed around org.jclouds.http
> package but I was unable to determine what HTTP client does JClouds use
> behind the scenes or if it's a custom implementation. Could I get some
> feedback whether my assumptions are correct and how hard would it be to fix
> this? This is the stacktrace:
>
>
> PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException:
> unable to find valid certification path to requested target connecting to
> HEAD https://s3.demo.mydomain.com/productname HTTP/1.1
> at org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(
> BaseHttpCommandExecutorService.java:121)
> at org.jclouds.rest.internal.InvokeHttpMethod.invoke(
> InvokeHttpMethod.java:90)
> at org.jclouds.rest.internal.InvokeHttpMethod.apply(
> InvokeHttpMethod.java:73)
> at org.jclouds.rest.internal.InvokeHttpMethod.apply(
> InvokeHttpMethod.java:44)
> at org.jclouds.rest.internal.DelegatesToInvocationFunction.handle(
> DelegatesToInvocationFunction.java:156)
> at org.jclouds.rest.internal.DelegatesToInvocationFunction.invoke(
> DelegatesToInvocationFunction.java:123)
> at com.sun.proxy.$Proxy146.bucketExists(Unknown Source)
> at org.jclouds.s3.blobstore.S3BlobStore.containerExists(
> S3BlobStore.java:131)
> at com.redacted.util.storage.S3Storage.saveBlob(S3Storage.java:42)
> at com.redacted.util.storage.BlobStorageImpl.saveBlob(
> BlobStorageImpl.java:19)
> at com.redacted.api.rest.v1.resources.ImagesResourceImpl.createTenant(
> ImagesResourceImpl.java:90)
> at com.redacted.api.rest.v1.resources.ImagesResourceImpl$
> Proxy$_$$_WeldSubclass.createTenant$$super(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocation
> Context.proceedInternal(TerminalAroundInvokeInvocationContext.java:49)
> at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.
> proceed(AroundInvokeInvocationContext.java:77)
> at com.redacted.api.rest.v1.interceptors.
> ValidatePermissionsInterceptor.checkOwnership(
> ValidatePermissionsInterceptor.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$
> SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74)
> at org.jboss.weld.interceptor.proxy.NonTerminalAroundInvokeInvocat
> ionContext.proceedInternal(NonTerminalAroundInvokeInvocat
> ionContext.java:64)
> at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.
> proceed(AroundInvokeInvocationContext.java:77)
> at com.redacted.api.rest.v1.interceptors.TransactionalInterceptor.
> manageTransaction(TransactionalInterceptor.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(
>