[
https://issues.apache.org/jira/browse/JCLOUDS-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14179962#comment-14179962
]
Adrian Cole edited comment on JCLOUDS-753 at 10/22/14 2:55 PM:
---------------------------------------------------------------
Downgraded the issue as described to minor.
http://markmail.org/thread/mtzwkcg3uxcgcvqk
In summary, jclouds does not interfere with the default ssl context used by
*any* http driver, except apachehc. In that case, it uses TLS. There are
providers in labs, fcgp and also azurecompute who do muck with it, but nothing
out of labs.
POODLE is a very hard to pull off MITM attack (especially considering this is
java code).
The issue as described initially is discussing the "untrusted" ssl context
which is only used when "jclouds.trust-all-certs" is set. Trusting all certs is
a much easier MITM attack.
I'm not saying to not switch the string, but certainly this is not a critical
issue, as the SSLContext used when "jclouds.trust-all-certs" is not set would
only be if someone added a guice module to do that.
{code}
@Inject(optional = true)
protected Supplier<SSLContext> sslContextSupplier;
{code}
https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/JavaUrlHttpCommandExecutorService.java#L80
ApacheHC is generally poorly written. I can understand how people can be
confused by it. When "untrusted" isn't in place, here's how it sets up an ssl
context.
{code}
SSLContext context = SSLContext.getInstance("TLS");
{code}
https://github.com/jclouds/jclouds/blob/master/drivers/apachehc/src/main/java/org/jclouds/http/apachehc/config/ApacheHCHttpCommandExecutorServiceModule.java#L116
Side-notes when raising "critical" security issues, include code links. Doing a
search on SSLContext and pasting something out of context can confuse people
and spread FUD. Some of us have access to security experts and can actually
help vet problems or suggest work arounds to things. I don't know if we have a
typical practice, as for example we didn't discuss larger problems such as
SHELLSHOCK. In other words [~diwaker] don't take this personally. Your intent
was good and I understand you meant well.
was (Author: adriancole):
Downgraded the issue as described to minor.
http://markmail.org/thread/mtzwkcg3uxcgcvqk
In summary, jclouds does not interfere with the default ssl context used by
*any* http driver, except apachehc. In that case, it uses TLS. There are
providers in labs, fcgp and also azurecompute who do muck with it, but nothing
out of labs.
POODLE is a very hard to pull off MITM attack (especially considering this is
java code).
The issue as described initially is discussing the "untrusted" ssl context
which is only used when "jclouds.trust-all-certs" is set. Trusting all certs is
a much easier MITM attack.
I'm not saying to not switch the string, but certainly this is not a critical
issue, as the SSLContext used when "jclouds.trust-all-certs" is not set would
only be if someone added a guice module to do that.
{code}
@Inject(optional = true)
protected Supplier<SSLContext> sslContextSupplier;
{code}
https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/JavaUrlHttpCommandExecutorService.java#L80
ApacheHC is generally poorly written. I can understand how people can be
confused by it. When "untrusted" isn't in place, here's how it sets up an ssl
context.
{code}
SSLContext context = SSLContext.getInstance("TLS");
{code}
https://github.com/jclouds/jclouds/blob/master/drivers/apachehc/src/main/java/org/jclouds/http/apachehc/config/ApacheHCHttpCommandExecutorServiceModule.java#L116
Side-notes when raising "critical" security issues, include code links. Doing a
search on SSLContext and pasting something out of context can confuse people
and spread FUD. Some of us have access to security experts and can actually
help vet problems or suggest work arounds to things. I don't know if we have a
typical practice, as for example we didn't discuss larger problems such as
POODLE. In other words [~diwaker] don't take this personally. Your intent was
good and I understand you meant well.
> Investigate HttpCommandExecutorService(s) with regards to POODLE
> ----------------------------------------------------------------
>
> Key: JCLOUDS-753
> URL: https://issues.apache.org/jira/browse/JCLOUDS-753
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-core, jclouds-drivers
> Affects Versions: 1.7.3, 1.8.0
> Reporter: Diwaker Gupta
> Priority: Minor
> Attachments: disable-sslv3.patch
>
>
> SSLModule configures the SSLContext when using "untrusted" configuration:
> {noformat}
> sc = SSLContext.getInstance("SSL");
> sc.init(null, new TrustManager[] { trustAllCerts }, new
> SecureRandom());
> {noformat}
> This makes the client end of the SSL connection vulnerable to POODLE
> (http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html)
> jclouds should consider enforcing TLS on all client connections, even on ones
> already susceptible to MITM attacks.
> We should also investigate other uses of SSLContext in jclouds.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
