> +If you are concerned about secure connections, it is almost never a good > idea to use this option in the first place. If you absolutely need to trust > all certificates _and_ disable SSLv3, you can: > + > + * create an SSLContext with the appropriate settings (see > [SSLModule](https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/config/SSLModule.java) > for an example of how to create a trust manager that trusts all certs) > + * set it as the default socket factory for HttpsURLConnection as described > above > + * set `jclouds.trust-all-certs` to false, to prevent jclouds from using > its own SSLContext > + > +2) If you are using the [Azure > Compute](https://github.com/jclouds/jclouds-labs/tree/master/azurecompute) or > [FCGP](https://github.com/jclouds/jclouds-labs/tree/master/fgcp) labs > providers > + > +jclouds sets a specific SSL configuration for these providers to support the > key-based authentication they require. If you are using either of these > providers and need to disable SSLv3, follow the same steps as above > + > +* create an SSLContext with the appropriate settings (see > [here](https://github.com/jclouds/jclouds-labs/blob/master/azurecompute/src/main/java/org/jclouds/azurecompute/suppliers/SSLContextWithKeysSupplier.java) > for Azure Compute and > [here](https://github.com/jclouds/jclouds-labs/blob/master/fgcp/src/main/java/org/jclouds/fujitsu/fgcp/suppliers/SSLContextWithKeysSupplier.java) > for FCGP) > + * set it as the default socket factory for HttpsURLConnection as described > above > + > +#### Why does jclouds not simply disable SSLv3 for all secure connections? > + > +At this point in time, it is not possible to determine the impact that > disabling SSLv3 for secure connections to **all** providers (supported and > custom) would have on functionality. Many providers have already disabled > SSLv3 on the server side of the connection, protecting users automatically.
I would say that jclouds isn't vulnerable, it is the application that allows issuing arbitrary untrusted requests. Better yet, say nothing. Basically those interested in the relationship to jclouds and the recently announced POODLE (link to poodle) attack should read our blog on the topic. In that blog, state the facts (ex what the components and cite known malpractice like trust all certs). Provide links to jiras that we logged that impede disabling ssl Provide links to folks authoritative on the subject and encourage them to assess themselves. That's it. Less assessing on behalf of unknown application or absorbing responsibility for unknown deployments, only facts and followup! Imagine if we did this for every recent vulnerability thay exists somewhere in the transport layer, we would only be able to afford short but sweet. Sadly, this is all I can afford to spend on this topic, so give your best as we all need to move onto things that are far more important than this. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-site/pull/138/files#r19319337
