Re: Using JClouds without TLSv1.0

[Ignasi Barrera]

Great to see it worked in the end! :)

On 10 March 2016 at 15:17, Mop Sophia  wrote:
> Nice ! It works fine !
>
> Thank you very much Ignasi ;)
>
> 2016-03-10 15:10 GMT+01:00 Ignasi Barrera :
>>
>> OK, then try this. Create a class like this one [1], that implements
>> the EndpointToSupplierAdminURI, and just returns the public url
>> instead of the admin one. Then, bind the EndpointToSupplierAdminURI to
>> your class, and that should work fine.
>>
>>
>> [1]
>> https://github.com/jclouds/jclouds/blob/master/apis/openstack-keystone/src/main/java/org/jclouds/openstack/keystone/v2_0/functions/AdminURL.java
>>
>> On 10 March 2016 at 11:22, Mop Sophia  wrote:
>> > It seems that I'm not able to put PublicURLOrInternalIfNull.class as a
>> > parameter of to() method because PublicURLOrInternalIfNull does not
>> > inherit
>> > from EndpointToSupplierAdminURI...
>> >
>> > The method to(Class) in the type
>> > LinkedBindingBuilder is not applicable for
>> > the
>> > arguments (Class)
>> >
>> >
>> > 2016-03-10 10:23 GMT+01:00 Ignasi Barrera :
>> >>
>> >> (Moving back the thread to the jclouds user list)
>> >>
>> >> Looking at the code, it seems that the User, Token and Tenant apis
>> >> from keystone use the admin endpoint by default. You can try to change
>> >> the default behavior and let the public endpoint be picked instead of
>> >> the admin one. Add the following module to the list of modules you
>> >> pass to the context builder:
>> >>
>> >> new AbstractModule() {
>> >>@Override protected void configure() {
>> >>
>> >>
>> >> bind(EndpointToSupplierAdminURI.class).to(PublicURLOrInternalIfNull.class).in(Scopes.SINGLETON);
>> >>}
>> >> }
>> >>
>> >> If you need to access the admin apis from outside the network, though,
>> >> you could consider configuring the endpoints in your OpenStack
>> >> installation to provide a public IP in the admin endpoint too.
>> >>
>> >> Let's see if this works!
>> >>
>> >> On 10 March 2016 at 08:53, Mop Sophia  wrote:
>> >> > Yes, it's what I checked. The login to Keystone is ok, the service
>> >> > catalog
>> >> > is returned, then jclouds uses the adminURL to send the request to
>> >> > check
>> >> > the
>> >> > token. When I search the endpoint used by jclouds in the message
>> >> > returned by
>> >> > Keystone, the only one occurence is the adminURL of Keystone.
>> >> > Maybe, the url used is depending of service used ? Maybe, the
>> >> > adminURL
>> >> > is
>> >> > used because I use the TokenApi ?
>> >> >
>> >> > Here is the log :
>> >> > [DEBUG] org.jclouds.rest.internal.InvokeHttpMethod - >> invoking
>> >> > AuthenticationApi.authenticateWithTenantNameAndCredentials
>> >> > [DEBUG] org.jclouds.http.okhttp.OkHttpCommandExecutorService -
>> >> > Sending
>> >> > request -1336091735: POST https://ow:5000/v2.0/tokens HTTP/1.1
>> >> > [DEBUG] jclouds.wire - >>
>> >> >
>> >> >
>> >> > "{"auth":{"passwordCredentials":{"username":"uuu","password":"ppp"},"tenantName":"ttt"}}"
>> >> > [DEBUG] jclouds.headers - >> POST https://ow:5000/v2.0/tokens
>> >> > HTTP/1.1
>> >> > [DEBUG] jclouds.headers - >> Accept: application/json
>> >> > [DEBUG] jclouds.headers - >> Content-Type: application/json
>> >> > [DEBUG] jclouds.headers - >> Content-Length: 136
>> >> > Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
>> >> > Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
>> >> > Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
>> >> > Ignoring unsupported cipher suite:
>> >> > TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
>> >> > Ignoring unsupported cipher suite:
>> >> > TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
>> >> > Ignoring unsupported cipher suite:
>> >> > TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
>> >> > Ignoring unsupported cipher suite:
>> >> > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
>> >> > Ignoring unsupported cipher suite:
>> >> > TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
>> >> > Ignoring unsupported cipher suite:
>> >> > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
>> >> > Ignoring unsupported cipher suite:
>> >> > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
>> >> > Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256
>> >> > Ignoring unavailable cipher suite:
>> >> > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
>> >> > Ignoring unsupported cipher suite:
>> >> > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
>> >> > Ignoring unsupported cipher suite:
>> >> > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
>> >> > Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
>> >> > Ignoring unsupported cipher suite:
>> >> > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
>> >> > Ignoring unsupported cipher suite:
>> >> > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
>> >> > Ignoring unsupported cipher suite:
>> >> > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
>> >> > Ignoring unavailable cipher suite:
>> >> > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
>> >> > Ignoring unavailable cipher suite: 

Re: Using JClouds without TLSv1.0

[Mop Sophia]

Nice ! It works fine !

Thank you very much Ignasi ;)

2016-03-10 15:10 GMT+01:00 Ignasi Barrera :

> OK, then try this. Create a class like this one [1], that implements
> the EndpointToSupplierAdminURI, and just returns the public url
> instead of the admin one. Then, bind the EndpointToSupplierAdminURI to
> your class, and that should work fine.
>
>
> [1]
> https://github.com/jclouds/jclouds/blob/master/apis/openstack-keystone/src/main/java/org/jclouds/openstack/keystone/v2_0/functions/AdminURL.java
>
> On 10 March 2016 at 11:22, Mop Sophia  wrote:
> > It seems that I'm not able to put PublicURLOrInternalIfNull.class as a
> > parameter of to() method because PublicURLOrInternalIfNull does not
> inherit
> > from EndpointToSupplierAdminURI...
> >
> > The method to(Class) in the type
> > LinkedBindingBuilder is not applicable for
> the
> > arguments (Class)
> >
> >
> > 2016-03-10 10:23 GMT+01:00 Ignasi Barrera :
> >>
> >> (Moving back the thread to the jclouds user list)
> >>
> >> Looking at the code, it seems that the User, Token and Tenant apis
> >> from keystone use the admin endpoint by default. You can try to change
> >> the default behavior and let the public endpoint be picked instead of
> >> the admin one. Add the following module to the list of modules you
> >> pass to the context builder:
> >>
> >> new AbstractModule() {
> >>@Override protected void configure() {
> >>
> >>
> bind(EndpointToSupplierAdminURI.class).to(PublicURLOrInternalIfNull.class).in(Scopes.SINGLETON);
> >>}
> >> }
> >>
> >> If you need to access the admin apis from outside the network, though,
> >> you could consider configuring the endpoints in your OpenStack
> >> installation to provide a public IP in the admin endpoint too.
> >>
> >> Let's see if this works!
> >>
> >> On 10 March 2016 at 08:53, Mop Sophia  wrote:
> >> > Yes, it's what I checked. The login to Keystone is ok, the service
> >> > catalog
> >> > is returned, then jclouds uses the adminURL to send the request to
> check
> >> > the
> >> > token. When I search the endpoint used by jclouds in the message
> >> > returned by
> >> > Keystone, the only one occurence is the adminURL of Keystone.
> >> > Maybe, the url used is depending of service used ? Maybe, the adminURL
> >> > is
> >> > used because I use the TokenApi ?
> >> >
> >> > Here is the log :
> >> > [DEBUG] org.jclouds.rest.internal.InvokeHttpMethod - >> invoking
> >> > AuthenticationApi.authenticateWithTenantNameAndCredentials
> >> > [DEBUG] org.jclouds.http.okhttp.OkHttpCommandExecutorService - Sending
> >> > request -1336091735: POST https://ow:5000/v2.0/tokens HTTP/1.1
> >> > [DEBUG] jclouds.wire - >>
> >> >
> >> >
> "{"auth":{"passwordCredentials":{"username":"uuu","password":"ppp"},"tenantName":"ttt"}}"
> >> > [DEBUG] jclouds.headers - >> POST https://ow:5000/v2.0/tokens
> HTTP/1.1
> >> > [DEBUG] jclouds.headers - >> Accept: application/json
> >> > [DEBUG] jclouds.headers - >> Content-Type: application/json
> >> > [DEBUG] jclouds.headers - >> Content-Length: 136
> >> > Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> >> > Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
> >> > Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
> >> > Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
> >> > Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
> >> > Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
> >> > Ignoring unsupported cipher suite:
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
> >> > Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
> >> > Ignoring unsupported cipher suite:
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> >> > Ignoring unsupported cipher suite:
> >> > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
> >> > Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256
> >> > Ignoring unavailable cipher suite:
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
> >> > Ignoring unsupported cipher suite:
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
> >> > Ignoring unsupported cipher suite:
> >> > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
> >> > Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
> >> > Ignoring unsupported cipher suite:
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
> >> > Ignoring unsupported cipher suite:
> >> > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
> >> > Ignoring unsupported cipher suite:
> >> > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
> >> > Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
> >> > Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA
> >> > Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256
> >> > Allow unsafe renegotiation: false
> >> > Allow legacy hello messages: true
> >> > Is initial handshake: true
> >> > Is secure renegotiation: false
> >> > Ignoring unavailable cipher suite: 

Re: Using JClouds without TLSv1.0

[Ignasi Barrera]

OK, then try this. Create a class like this one [1], that implements
the EndpointToSupplierAdminURI, and just returns the public url
instead of the admin one. Then, bind the EndpointToSupplierAdminURI to
your class, and that should work fine.


[1] 
https://github.com/jclouds/jclouds/blob/master/apis/openstack-keystone/src/main/java/org/jclouds/openstack/keystone/v2_0/functions/AdminURL.java

On 10 March 2016 at 11:22, Mop Sophia  wrote:
> It seems that I'm not able to put PublicURLOrInternalIfNull.class as a
> parameter of to() method because PublicURLOrInternalIfNull does not inherit
> from EndpointToSupplierAdminURI...
>
> The method to(Class) in the type
> LinkedBindingBuilder is not applicable for the
> arguments (Class)
>
>
> 2016-03-10 10:23 GMT+01:00 Ignasi Barrera :
>>
>> (Moving back the thread to the jclouds user list)
>>
>> Looking at the code, it seems that the User, Token and Tenant apis
>> from keystone use the admin endpoint by default. You can try to change
>> the default behavior and let the public endpoint be picked instead of
>> the admin one. Add the following module to the list of modules you
>> pass to the context builder:
>>
>> new AbstractModule() {
>>@Override protected void configure() {
>>
>> bind(EndpointToSupplierAdminURI.class).to(PublicURLOrInternalIfNull.class).in(Scopes.SINGLETON);
>>}
>> }
>>
>> If you need to access the admin apis from outside the network, though,
>> you could consider configuring the endpoints in your OpenStack
>> installation to provide a public IP in the admin endpoint too.
>>
>> Let's see if this works!
>>
>> On 10 March 2016 at 08:53, Mop Sophia  wrote:
>> > Yes, it's what I checked. The login to Keystone is ok, the service
>> > catalog
>> > is returned, then jclouds uses the adminURL to send the request to check
>> > the
>> > token. When I search the endpoint used by jclouds in the message
>> > returned by
>> > Keystone, the only one occurence is the adminURL of Keystone.
>> > Maybe, the url used is depending of service used ? Maybe, the adminURL
>> > is
>> > used because I use the TokenApi ?
>> >
>> > Here is the log :
>> > [DEBUG] org.jclouds.rest.internal.InvokeHttpMethod - >> invoking
>> > AuthenticationApi.authenticateWithTenantNameAndCredentials
>> > [DEBUG] org.jclouds.http.okhttp.OkHttpCommandExecutorService - Sending
>> > request -1336091735: POST https://ow:5000/v2.0/tokens HTTP/1.1
>> > [DEBUG] jclouds.wire - >>
>> >
>> > "{"auth":{"passwordCredentials":{"username":"uuu","password":"ppp"},"tenantName":"ttt"}}"
>> > [DEBUG] jclouds.headers - >> POST https://ow:5000/v2.0/tokens HTTP/1.1
>> > [DEBUG] jclouds.headers - >> Accept: application/json
>> > [DEBUG] jclouds.headers - >> Content-Type: application/json
>> > [DEBUG] jclouds.headers - >> Content-Length: 136
>> > Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
>> > Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
>> > Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
>> > Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
>> > Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
>> > Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
>> > Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
>> > Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
>> > Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
>> > Ignoring unsupported cipher suite:
>> > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
>> > Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256
>> > Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
>> > Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
>> > Ignoring unsupported cipher suite:
>> > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
>> > Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
>> > Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
>> > Ignoring unsupported cipher suite:
>> > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
>> > Ignoring unsupported cipher suite:
>> > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
>> > Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
>> > Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA
>> > Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256
>> > Allow unsafe renegotiation: false
>> > Allow legacy hello messages: true
>> > Is initial handshake: true
>> > Is secure renegotiation: false
>> > Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
>> > Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
>> > Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
>> > Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
>> > Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
>> > Ignoring 

Re: Using JClouds without TLSv1.0

[Mop Sophia]

It seems that I'm not able to put PublicURLOrInternalIfNull.class as a
parameter of to() method because PublicURLOrInternalIfNull does not inherit
from EndpointToSupplierAdminURI...

The method to(Class) in the type
LinkedBindingBuilder is not applicable for the
arguments (Class)


2016-03-10 10:23 GMT+01:00 Ignasi Barrera :

> (Moving back the thread to the jclouds user list)
>
> Looking at the code, it seems that the User, Token and Tenant apis
> from keystone use the admin endpoint by default. You can try to change
> the default behavior and let the public endpoint be picked instead of
> the admin one. Add the following module to the list of modules you
> pass to the context builder:
>
> new AbstractModule() {
>@Override protected void configure() {
>
> bind(EndpointToSupplierAdminURI.class).to(PublicURLOrInternalIfNull.class).in(Scopes.SINGLETON);
>}
> }
>
> If you need to access the admin apis from outside the network, though,
> you could consider configuring the endpoints in your OpenStack
> installation to provide a public IP in the admin endpoint too.
>
> Let's see if this works!
>
> On 10 March 2016 at 08:53, Mop Sophia  wrote:
> > Yes, it's what I checked. The login to Keystone is ok, the service
> catalog
> > is returned, then jclouds uses the adminURL to send the request to check
> the
> > token. When I search the endpoint used by jclouds in the message
> returned by
> > Keystone, the only one occurence is the adminURL of Keystone.
> > Maybe, the url used is depending of service used ? Maybe, the adminURL is
> > used because I use the TokenApi ?
> >
> > Here is the log :
> > [DEBUG] org.jclouds.rest.internal.InvokeHttpMethod - >> invoking
> > AuthenticationApi.authenticateWithTenantNameAndCredentials
> > [DEBUG] org.jclouds.http.okhttp.OkHttpCommandExecutorService - Sending
> > request -1336091735: POST https://ow:5000/v2.0/tokens HTTP/1.1
> > [DEBUG] jclouds.wire - >>
> >
> "{"auth":{"passwordCredentials":{"username":"uuu","password":"ppp"},"tenantName":"ttt"}}"
> > [DEBUG] jclouds.headers - >> POST https://ow:5000/v2.0/tokens HTTP/1.1
> > [DEBUG] jclouds.headers - >> Accept: application/json
> > [DEBUG] jclouds.headers - >> Content-Type: application/json
> > [DEBUG] jclouds.headers - >> Content-Length: 136
> > Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> > Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
> > Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
> > Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
> > Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
> > Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
> > Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
> > Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
> > Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> > Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
> > Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256
> > Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
> > Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
> > Ignoring unsupported cipher suite:
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
> > Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
> > Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
> > Ignoring unsupported cipher suite:
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
> > Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
> > Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
> > Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA
> > Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256
> > Allow unsafe renegotiation: false
> > Allow legacy hello messages: true
> > Is initial handshake: true
> > Is secure renegotiation: false
> > Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> > Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
> > Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
> > Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
> > Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
> > Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> > Ignoring unavailable cipher suite: TLS_ECDH_anon_WITH_AES_256_CBC_SHA
> > Ignoring unavailable cipher suite: TLS_DH_anon_WITH_AES_256_CBC_SHA
> > Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
> > Ignoring unavailable cipher suite: TLS_DH_anon_WITH_AES_256_CBC_SHA256
> > Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256
> > Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
> > Ignoring unavailable cipher suite:
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
> 

Re: Using JClouds without TLSv1.0

[Ignasi Barrera]

(Moving back the thread to the jclouds user list)

Looking at the code, it seems that the User, Token and Tenant apis
from keystone use the admin endpoint by default. You can try to change
the default behavior and let the public endpoint be picked instead of
the admin one. Add the following module to the list of modules you
pass to the context builder:

new AbstractModule() {
   @Override protected void configure() {
  
bind(EndpointToSupplierAdminURI.class).to(PublicURLOrInternalIfNull.class).in(Scopes.SINGLETON);
   }
}

If you need to access the admin apis from outside the network, though,
you could consider configuring the endpoints in your OpenStack
installation to provide a public IP in the admin endpoint too.

Let's see if this works!

On 10 March 2016 at 08:53, Mop Sophia  wrote:
> Yes, it's what I checked. The login to Keystone is ok, the service catalog
> is returned, then jclouds uses the adminURL to send the request to check the
> token. When I search the endpoint used by jclouds in the message returned by
> Keystone, the only one occurence is the adminURL of Keystone.
> Maybe, the url used is depending of service used ? Maybe, the adminURL is
> used because I use the TokenApi ?
>
> Here is the log :
> [DEBUG] org.jclouds.rest.internal.InvokeHttpMethod - >> invoking
> AuthenticationApi.authenticateWithTenantNameAndCredentials
> [DEBUG] org.jclouds.http.okhttp.OkHttpCommandExecutorService - Sending
> request -1336091735: POST https://ow:5000/v2.0/tokens HTTP/1.1
> [DEBUG] jclouds.wire - >>
> "{"auth":{"passwordCredentials":{"username":"uuu","password":"ppp"},"tenantName":"ttt"}}"
> [DEBUG] jclouds.headers - >> POST https://ow:5000/v2.0/tokens HTTP/1.1
> [DEBUG] jclouds.headers - >> Accept: application/json
> [DEBUG] jclouds.headers - >> Content-Type: application/json
> [DEBUG] jclouds.headers - >> Content-Length: 136
> Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
> Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
> Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
> Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
> Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
> Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
> Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
> Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
> Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256
> Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
> Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
> Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
> Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
> Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
> Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
> Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
> Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
> Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA
> Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256
> Allow unsafe renegotiation: false
> Allow legacy hello messages: true
> Is initial handshake: true
> Is secure renegotiation: false
> Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
> Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
> Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
> Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
> Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> Ignoring unavailable cipher suite: TLS_ECDH_anon_WITH_AES_256_CBC_SHA
> Ignoring unavailable cipher suite: TLS_DH_anon_WITH_AES_256_CBC_SHA
> Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
> Ignoring unavailable cipher suite: TLS_DH_anon_WITH_AES_256_CBC_SHA256
> Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256
> Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
> Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
> Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
> Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
> Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
> Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA
> %% No cached client session
> *** ClientHello, TLSv1.2
> RandomCookie:  GMT: 1440818357 bytes = { 59, 197, 208, 174, 148, 240, 177,
> 206, 212, 36, 163, 98, 134, 77, 180, 86, 73, 55, 27, 102, 106, 53, 243, 123,
> 176, 

Re: Using JClouds without TLSv1.0

[Ignasi Barrera]

Yes there is, but if I'm not wrong the jclouds default is to use the public
url and fallback to the internal one. Do you have any special Guice module
configuration?
El 9/3/2016 5:36 p. m., "Mop Sophia"  escribió:

> Thanks Ignasi, it's ok when using the proxy properties (it was the way I
> was using before going to okhttp)
>
> In fact, the issue is the connection to the service on this platform. The
> login using keystone is ok, but the use of service fails :(
> It seems JClouds uses the adminURL, I would like to use publicURL, I don't
> if there is something configure it...
>
> My case is to check a tenant witth this code :
> keystoneApi = ContextBuilder.newBuilder(provider)
>   .endpoint(endpoint)
>   .credentials(identity, password)
>   .modules(modules)
>   .overrides(overrides)
>   .buildApi(KeystoneApi.class);
>
> // Request Openstack Keystone to validate the token
> Token token = keystoneApi.getTokenApi().get().get(authToken);
> // Fails because JClouds get the adminUrl of keystone to make
> the request
>
> Regards,
>
> Stéphane
>
>
>
> 2016-03-09 13:32 GMT+01:00 Ignasi Barrera :
>
>> Don't configure the proxy in the client supplier. Just configure it
>> the "standard jclouds way", by configuring the proxy properties as
>> "overrides" when creating the context:
>>
>> http://jclouds-javadocs.elasticbeanstalk.com/constant-values.html#org.jclouds.Constants.PROPERTY_PROXY_HOST
>>
>> On 9 March 2016 at 13:18, Mop Sophia  wrote:
>> > Hi,
>> >
>> > Thanks for this code Ignasi, but it seems the client configuration is
>> not
>> > used, because the client tries a direct connection without proxy :(
>> > Here is my code :
>> >
>> > public static class TLSOkHttpClientSupplier implements
>> > OkHttpClientSupplier {
>> >@Override public OkHttpClient get() {
>> >   OkHttpClient client = new OkHttpClient();
>> >   ConnectionSpec tlsSpec =
>> >   new ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
>> >  .tlsVersions(TlsVersion.TLS_1_1, TlsVersion.TLS_1_2)
>> >  .build();
>> >   ConnectionSpec cleartextSpec =
>> >  new
>> ConnectionSpec.Builder(ConnectionSpec.CLEARTEXT).build();
>> >   client.setConnectionSpecs(ImmutableList.of(tlsSpec,
>> > cleartextSpec));
>> >   client.setProxy(new Proxy(Proxy.Type.HTTP, new
>> > InetSocketAddress("10.182.110.12", 8080)));
>> >   return client;
>> >}
>> > }
>> >
>> >
>> > Module tlsModule = new AbstractModule() {
>> >@Override protected void configure() {
>> >
>> > bind(OkHttpClientSupplier.class).to(TLSOkHttpClientSupplier.class);
>> >}
>> > };
>> >
>> >
>> > Iterable modules = ImmutableSet.of(new
>> > SLF4JLoggingModule(),tlsModule, new
>> OkHttpCommandExecutorServiceModule());
>> >
>> > Properties overrides = new Properties();
>> >
>> > overrides.setProperty(Constants.PROPERTY_LOGGER_WIRE_LOG_SENSITIVE_INFO,
>> > true + "");
>> >
>> > keystoneApi = ContextBuilder.newBuilder(provider)
>> >   .endpoint(endpoint)
>> >   .credentials(identity, password)
>> >   .modules(modules)
>> >   .overrides(overrides)
>> >   .buildApi(KeystoneApi.class);
>> >
>> >
>> > Any idea of my mistake ?
>> >
>> > Regards,
>> >
>> > Stéphane
>> >
>> >
>> > 2016-03-05 1:28 GMT+01:00 Ignasi Barrera :
>> >>
>> >> Hi!
>> >>
>> >> Andrew's link will provide you the context you need.
>> >>
>> >> I don't know if there is a proper way of configuring this using the
>> >> default HTTP driver, but here is a specific example using the OkHttp
>> >> one:
>> >>
>> >> First you will need to create an OkHttpClientSupplier that creates the
>> >> http client with the desired connection configuration:
>> >>
>> >> public class TLSOkHttpClientSupplier implements OkHttpClientSupplier {
>> >>@Override public OkHttpClient get() {
>> >>   OkHttpClient client = new OkHttpClient();
>> >>   ConnectionSpec tlsSpec =
>> >>   new ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
>> >>  .tlsVersions(TlsVersion.TLS_1_1, TlsVersion.TLS_1_2)
>> >>  .build();
>> >>   ConnectionSpec cleartextSpec =
>> >>  new ConnectionSpec.Builder(ConnectionSpec.CLEARTEXT).build();
>> >>   client.setConnectionSpecs(ImmutableList.of(tlsSpec,
>> cleartextSpec));
>> >>   return client;
>> >>}
>> >> }
>> >>
>> >> Once you have the class that will create the OkHttpClient you just
>> >> have to inject it in the Guice context and configure the OkHttp driver
>> >> to be used to manage the HTTP connections. Both things are achieved by
>> >> providing additional modules when creating the context:
>> >>
>> >> // Create a Guice module that 

Re: Using JClouds without TLSv1.0

[Ignasi Barrera]

Don't configure the proxy in the client supplier. Just configure it
the "standard jclouds way", by configuring the proxy properties as
"overrides" when creating the context:
http://jclouds-javadocs.elasticbeanstalk.com/constant-values.html#org.jclouds.Constants.PROPERTY_PROXY_HOST

On 9 March 2016 at 13:18, Mop Sophia  wrote:
> Hi,
>
> Thanks for this code Ignasi, but it seems the client configuration is not
> used, because the client tries a direct connection without proxy :(
> Here is my code :
>
> public static class TLSOkHttpClientSupplier implements
> OkHttpClientSupplier {
>@Override public OkHttpClient get() {
>   OkHttpClient client = new OkHttpClient();
>   ConnectionSpec tlsSpec =
>   new ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
>  .tlsVersions(TlsVersion.TLS_1_1, TlsVersion.TLS_1_2)
>  .build();
>   ConnectionSpec cleartextSpec =
>  new ConnectionSpec.Builder(ConnectionSpec.CLEARTEXT).build();
>   client.setConnectionSpecs(ImmutableList.of(tlsSpec,
> cleartextSpec));
>   client.setProxy(new Proxy(Proxy.Type.HTTP, new
> InetSocketAddress("10.182.110.12", 8080)));
>   return client;
>}
> }
>
>
> Module tlsModule = new AbstractModule() {
>@Override protected void configure() {
>
> bind(OkHttpClientSupplier.class).to(TLSOkHttpClientSupplier.class);
>}
> };
>
>
> Iterable modules = ImmutableSet.of(new
> SLF4JLoggingModule(),tlsModule, new OkHttpCommandExecutorServiceModule());
>
> Properties overrides = new Properties();
>
> overrides.setProperty(Constants.PROPERTY_LOGGER_WIRE_LOG_SENSITIVE_INFO,
> true + "");
>
> keystoneApi = ContextBuilder.newBuilder(provider)
>   .endpoint(endpoint)
>   .credentials(identity, password)
>   .modules(modules)
>   .overrides(overrides)
>   .buildApi(KeystoneApi.class);
>
>
> Any idea of my mistake ?
>
> Regards,
>
> Stéphane
>
>
> 2016-03-05 1:28 GMT+01:00 Ignasi Barrera :
>>
>> Hi!
>>
>> Andrew's link will provide you the context you need.
>>
>> I don't know if there is a proper way of configuring this using the
>> default HTTP driver, but here is a specific example using the OkHttp
>> one:
>>
>> First you will need to create an OkHttpClientSupplier that creates the
>> http client with the desired connection configuration:
>>
>> public class TLSOkHttpClientSupplier implements OkHttpClientSupplier {
>>@Override public OkHttpClient get() {
>>   OkHttpClient client = new OkHttpClient();
>>   ConnectionSpec tlsSpec =
>>   new ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
>>  .tlsVersions(TlsVersion.TLS_1_1, TlsVersion.TLS_1_2)
>>  .build();
>>   ConnectionSpec cleartextSpec =
>>  new ConnectionSpec.Builder(ConnectionSpec.CLEARTEXT).build();
>>   client.setConnectionSpecs(ImmutableList.of(tlsSpec, cleartextSpec));
>>   return client;
>>}
>> }
>>
>> Once you have the class that will create the OkHttpClient you just
>> have to inject it in the Guice context and configure the OkHttp driver
>> to be used to manage the HTTP connections. Both things are achieved by
>> providing additional modules when creating the context:
>>
>> // Create a Guice module that will bind your supplier implementation
>> // to the injection context
>> Module tlsModule = new AbstractModule() {
>>@Override protected void configure() {
>>   bind(OkHttpClientSupplier.class).to(TLSOkHttpClientSupplier.class);
>>}
>> };
>>
>> // Create the context loading the OkHttpDriver and your custom module
>> ContextBuilder.newBuilder("provider")
>>.modules(ImmutableSet.of(tlsModule,
>>   new OkHttpCommandExecutorServiceModule()))
>>.build()
>>
>> Note than in order to use the OkHttp driver you'll have to add the
>> "org.apache.jclouds.driver/jclouds-okhttp" dependency to your pom.xml.
>>
>>
>> HTH!
>>
>> I.
>>
>> On 4 March 2016 at 22:23, Andrew Phillips  wrote:
>> > Hi Stéphane
>> >
>> >> Any idea of code to configure my http client with TLSv1.1 or TLSv1.2
>> >> instead of TLSv1.0, please ?
>> >
>> >
>> > The following blog post doesn't provide a step-by-step solution, but
>> > should
>> > hopefully help:
>> >
>> > https://jclouds.apache.org/blog/2014/10/25/poodle-and-jclouds/
>> >
>> > Regards
>> >
>> > ap
>
>

Re: Using JClouds without TLSv1.0

[Mop Sophia]

Hi,

Thanks for this code Ignasi, but it seems the client configuration is not
used, because the client tries a direct connection without proxy :(
Here is my code :

public static class TLSOkHttpClientSupplier implements
OkHttpClientSupplier {
   @Override public OkHttpClient get() {
  OkHttpClient client = new OkHttpClient();
  ConnectionSpec tlsSpec =
  new ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
 .tlsVersions(TlsVersion.TLS_1_1, TlsVersion.TLS_1_2)
 .build();
  ConnectionSpec cleartextSpec =
 new ConnectionSpec.Builder(ConnectionSpec.CLEARTEXT).build();
  client.setConnectionSpecs(ImmutableList.of(tlsSpec,
cleartextSpec));
  client.setProxy(new Proxy(Proxy.Type.HTTP, new
InetSocketAddress("10.182.110.12", 8080)));
  return client;
   }
}


Module tlsModule = new AbstractModule() {
   @Override protected void configure() {

bind(OkHttpClientSupplier.class).to(TLSOkHttpClientSupplier.class);
   }
};


Iterable modules = ImmutableSet.of(new
SLF4JLoggingModule(),tlsModule, new OkHttpCommandExecutorServiceModule());

Properties overrides = new Properties();

overrides.setProperty(Constants.PROPERTY_LOGGER_WIRE_LOG_SENSITIVE_INFO,
true + "");

keystoneApi = ContextBuilder.newBuilder(provider)
  .endpoint(endpoint)
  .credentials(identity, password)
  .modules(modules)
  .overrides(overrides)
  .buildApi(KeystoneApi.class);


Any idea of my mistake ?

Regards,

Stéphane


2016-03-05 1:28 GMT+01:00 Ignasi Barrera :

> Hi!
>
> Andrew's link will provide you the context you need.
>
> I don't know if there is a proper way of configuring this using the
> default HTTP driver, but here is a specific example using the OkHttp
> one:
>
> First you will need to create an OkHttpClientSupplier that creates the
> http client with the desired connection configuration:
>
> public class TLSOkHttpClientSupplier implements OkHttpClientSupplier {
>@Override public OkHttpClient get() {
>   OkHttpClient client = new OkHttpClient();
>   ConnectionSpec tlsSpec =
>   new ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
>  .tlsVersions(TlsVersion.TLS_1_1, TlsVersion.TLS_1_2)
>  .build();
>   ConnectionSpec cleartextSpec =
>  new ConnectionSpec.Builder(ConnectionSpec.CLEARTEXT).build();
>   client.setConnectionSpecs(ImmutableList.of(tlsSpec, cleartextSpec));
>   return client;
>}
> }
>
> Once you have the class that will create the OkHttpClient you just
> have to inject it in the Guice context and configure the OkHttp driver
> to be used to manage the HTTP connections. Both things are achieved by
> providing additional modules when creating the context:
>
> // Create a Guice module that will bind your supplier implementation
> // to the injection context
> Module tlsModule = new AbstractModule() {
>@Override protected void configure() {
>   bind(OkHttpClientSupplier.class).to(TLSOkHttpClientSupplier.class);
>}
> };
>
> // Create the context loading the OkHttpDriver and your custom module
> ContextBuilder.newBuilder("provider")
>.modules(ImmutableSet.of(tlsModule,
>   new OkHttpCommandExecutorServiceModule()))
>.build()
>
> Note than in order to use the OkHttp driver you'll have to add the
> "org.apache.jclouds.driver/jclouds-okhttp" dependency to your pom.xml.
>
>
> HTH!
>
> I.
>
> On 4 March 2016 at 22:23, Andrew Phillips  wrote:
> > Hi Stéphane
> >
> >> Any idea of code to configure my http client with TLSv1.1 or TLSv1.2
> >> instead of TLSv1.0, please ?
> >
> >
> > The following blog post doesn't provide a step-by-step solution, but
> should
> > hopefully help:
> >
> > https://jclouds.apache.org/blog/2014/10/25/poodle-and-jclouds/
> >
> > Regards
> >
> > ap
>

Re: Using JClouds without TLSv1.0

[Ignasi Barrera]

Hi!

Andrew's link will provide you the context you need.

I don't know if there is a proper way of configuring this using the
default HTTP driver, but here is a specific example using the OkHttp
one:

First you will need to create an OkHttpClientSupplier that creates the
http client with the desired connection configuration:

public class TLSOkHttpClientSupplier implements OkHttpClientSupplier {
   @Override public OkHttpClient get() {
  OkHttpClient client = new OkHttpClient();
  ConnectionSpec tlsSpec =
  new ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
 .tlsVersions(TlsVersion.TLS_1_1, TlsVersion.TLS_1_2)
 .build();
  ConnectionSpec cleartextSpec =
 new ConnectionSpec.Builder(ConnectionSpec.CLEARTEXT).build();
  client.setConnectionSpecs(ImmutableList.of(tlsSpec, cleartextSpec));
  return client;
   }
}

Once you have the class that will create the OkHttpClient you just
have to inject it in the Guice context and configure the OkHttp driver
to be used to manage the HTTP connections. Both things are achieved by
providing additional modules when creating the context:

// Create a Guice module that will bind your supplier implementation
// to the injection context
Module tlsModule = new AbstractModule() {
   @Override protected void configure() {
  bind(OkHttpClientSupplier.class).to(TLSOkHttpClientSupplier.class);
   }
};

// Create the context loading the OkHttpDriver and your custom module
ContextBuilder.newBuilder("provider")
   .modules(ImmutableSet.of(tlsModule,
  new OkHttpCommandExecutorServiceModule()))
   .build()

Note than in order to use the OkHttp driver you'll have to add the
"org.apache.jclouds.driver/jclouds-okhttp" dependency to your pom.xml.


HTH!

I.

On 4 March 2016 at 22:23, Andrew Phillips  wrote:
> Hi Stéphane
>
>> Any idea of code to configure my http client with TLSv1.1 or TLSv1.2
>> instead of TLSv1.0, please ?
>
>
> The following blog post doesn't provide a step-by-step solution, but should
> hopefully help:
>
> https://jclouds.apache.org/blog/2014/10/25/poodle-and-jclouds/
>
> Regards
>
> ap

Re: Using JClouds without TLSv1.0

[Andrew Phillips]

Hi Stéphane


Any idea of code to configure my http client with TLSv1.1 or TLSv1.2
instead of TLSv1.0, please ?


The following blog post doesn't provide a step-by-step solution, but 
should hopefully help:


https://jclouds.apache.org/blog/2014/10/25/poodle-and-jclouds/

Regards

ap