You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@jclouds.apache.org by Andrew Phillips <no...@github.com> on 2014/10/20 05:01:00 UTC

[jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

You can merge this Pull Request by running:

  git pull https://github.com/jclouds/jclouds-site 1.8.1-release-notes

Or you can view, comment on it, or merge it online at:

  https://github.com/jclouds/jclouds-site/pull/138

-- Commit Summary --

  * Initial strawman

-- File Changes --

    M _config.yml (4)
    M _includes/navbar.html (1)
    A releasenotes/1.8.1.md (48)
    M releasenotes/index.md (1)

-- Patch Links --

https://github.com/jclouds/jclouds-site/pull/138.patch
https://github.com/jclouds/jclouds-site/pull/138.diff

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by Andrew Phillips <no...@github.com>.
> +1. [Highlights](#highlights)
> +1. [API Changes](#api)
> +1. [Known Issues](#issues)
> +1. [Reminder](#reminder)
> +1. [Credits](#credits)
> +1. [Test Results](#test)
> +
> +## <a id="intro"></a>Introduction
> +
> +You can read the official announcement at [Apache jclouds 1.8.1 released](TODO). You can read the details of the specific JIRA issues addressed in this release at the [JIRA Release Notes](TODO).
> +
> +To get jclouds, please see the [jclouds installation guide](/start/install/).
> +
> +## <a id="highlights"></a>Highlights
> +
> +* TODO

Nothing except for the Swift graduation here? Roll up, roll up with your changes!

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138/files#r19293108

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by Adrian Cole <no...@github.com>.
> +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.

Ps since we have no history of covering security vulnerabilities and this
is old news (10/14), there's always the option to leave it out. We haven't
had 100 people ask about this and posting something late as a part of
release notes adds coupling that isn't natural since 1.8.1 has nothing to
do with this.

It is probably better to make a separate announcement if we feel further
investment on this topic is actually worthwhile.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138/files#r19319651

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by CloudBees pull request builder plugin <no...@github.com>.
[jclouds-site-pull-requests #420](https://jclouds.ci.cloudbees.com/job/jclouds-site-pull-requests/420/) FAILURE
Looks like there's a problem with this pull request

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138#issuecomment-59992828

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by Adrian Cole <no...@github.com>.
> +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

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by jclouds-commentator <no...@github.com>.
  Go to http://f864ab384a031a3a42ff-7621ac03bcc980806fdaede83f69cfa7.r71.cf5.rackcdn.com/ to review your changes.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138#issuecomment-60349836

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by CloudBees pull request builder plugin <no...@github.com>.
[jclouds-site-pull-requests #421](https://jclouds.ci.cloudbees.com/job/jclouds-site-pull-requests/421/) SUCCESS
This pull request looks good

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138#issuecomment-59994398

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by Adrian Cole <no...@github.com>.
> +layout: post
> +slug: poole-jclouds
> +title: What POODLE means for jclouds
> +---
> +
> +[POODLE](http://googleonlinesecurity.blogspot.com.au/2014/10/this-poodle-bites-exploiting-ssl-30.html) is a recently discovered [man-in-the-middle attack](http://en.wikipedia.org/wiki/Man-in-the-middle_attack) against SSL. If you are communicating via SSL from Java applications, including jclouds 1.8.1 and prior versions, you are potentially vulnerable to this attack.
> +
> +<!--more-->
> +
> +Exploiting this vulnerability [is complicated](http://blog.erratasec.com/2014/10/some-poodle-notes.html#.VEb9voBdWIk) and currently requires the attacker to cause many specifically-crafted requests to be executed. It is not clear how this could be achieved if the target user is using jclouds, but the possibility remains, of course.
> +
> +#### What can I do to avoid being affected by POODLE?
> +
> +If you are concerned about POODLE, there are two main ways to avoid being affected:
> +
> +* ensure that your provider no longer supports SSLv3

nit: endpoint

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138/files#r19281834

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by CloudBees pull request builder plugin <no...@github.com>.
[jclouds-site-pull-requests #430](https://jclouds.ci.cloudbees.com/job/jclouds-site-pull-requests/430/) SUCCESS
This pull request looks good

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138#issuecomment-60503925

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by CloudBees pull request builder plugin <no...@github.com>.
[jclouds-site-pull-requests #423](https://jclouds.ci.cloudbees.com/job/jclouds-site-pull-requests/423/) SUCCESS
This pull request looks good

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138#issuecomment-60200012

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by CloudBees pull request builder plugin <no...@github.com>.
[jclouds-site-pull-requests #422](https://jclouds.ci.cloudbees.com/job/jclouds-site-pull-requests/422/) SUCCESS
This pull request looks good

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138#issuecomment-60199058

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by Andrew Phillips <no...@github.com>.
> jclouds-site-pull-requests #416 FAILURE

Interesting error:
```
Configuration file: /scratch/jenkins/workspace/jclouds-site-pull-requests/_config.yml
            Source: /scratch/jenkins/workspace/jclouds-site-pull-requests
       Destination: /scratch/jenkins/workspace/jclouds-site-pull-requests/_site
      Generating...   Liquid Exception: argument out of range in _layouts/releasenotes.html
error: argument out of range. Use --trace to view backtrace
Build step 'Execute shell' marked build as failure
```
Ignoring this for now - let's first get the doc ready...

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138#issuecomment-59679721

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by Adrian Cole <no...@github.com>.
> +// Example only! Choose the appropriate SSLContext settings for your scenario!
> +SSLContext sc = SSLContext.getInstance("TLS");
> +sc.init(null, null, null);
> +sc.getDefaultSSLParameters().setProtocols(new String[] { "TLSv1", "TLSv1.1", "TLSv1.2" });
> +HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
> +...
> +// use jclouds to make HTTPS connections to your cloud providers
> +```
> +
> +#### When does jclouds configure SSL connections itself?
> +
> +jclouds only changes the SSL connection settings (rather than inheriting them from the JVM) in two cases:
> +
> +1) If you are setting `jclouds.trust-all-certs=true`, i.e. are configuring jclouds to trust **all** certificates
> +
> +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:

Take out this paragraph and replace with something I mentioned earlier. Link edge cases to Jira.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138/files#r19282517

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by jclouds-commentator <no...@github.com>.
  Go to http://37ab8e9990534a255e08-36b111363a513e7d2159e338dd56a3fc.r80.cf5.rackcdn.com/ to review your changes.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138#issuecomment-60199127

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by CloudBees pull request builder plugin <no...@github.com>.
[jclouds-site-pull-requests #416](https://jclouds.ci.cloudbees.com/job/jclouds-site-pull-requests/416/) FAILURE
Looks like there's a problem with this pull request

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138#issuecomment-59678683

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by CloudBees pull request builder plugin <no...@github.com>.
[jclouds-site-pull-requests #431](https://jclouds.ci.cloudbees.com/job/jclouds-site-pull-requests/431/) SUCCESS
This pull request looks good

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138#issuecomment-60505574

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by Adrian Cole <no...@github.com>.
> +#### What can I do to avoid being affected by POODLE?
> +
> +If you are concerned about POODLE, there are two main ways to avoid being affected:
> +
> +* ensure that your provider no longer supports SSLv3
> +
> +Many cloud providers are disabling support for SSLv3 - the protocol version exploited by POODLE - on the server-side. Checking whether the cloud providers you are talking to using jclouds have removed support for SSLv3 is the easiest possible fix for you as a user, since it requires no changes to any of your client code.
> +
> +* configure your client code to not support SSLv3 connections
> +
> +See below for options on how to disable SSLv3 support for client applications using jclouds to talk to cloud providers.
> +
> +### Technical details
> +
> +#### How does POODLE relate to jclouds?
> +

POODLE is a transport level attack which requires instigating a fallback to SSLv3. Implementations of jclouds http driver (HttpCommandExecutorService) dictate TLS configuration. The default http driver inherits TLS configuration from (HttpsURLConnection)[http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/HttpsURLConnection.html].

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138/files#r19282379

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by Adrian Cole <no...@github.com>.
> +// use jclouds to make HTTPS connections to your cloud providers
> +```
> +
> +#### When does jclouds configure SSL connections itself?
> +
> +jclouds only changes the SSL connection settings (rather than inheriting them from the JVM) in two cases:
> +
> +1) If you are setting `jclouds.trust-all-certs=true`, i.e. are configuring jclouds to trust **all** certificates
> +
> +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

Just mention that these labs providers set TLS, but don't allow users to affect protocol fallback choices. *after we check to see if the endpoints are actually vulnerable*, we could say that they are, and so users should assess carefully usage prior to 1.8.2.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138/files#r19282631

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by Adrian Cole <no...@github.com>.
+1 I like that POODLE is simply a link and doesn't dominate the content on
the release.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138#issuecomment-60395907

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by Andrew Phillips <no...@github.com>.
> +* [openstack-swift API changes from 1.8.0 to 1.8.1](api-changes/openstack-swift/)
> +
> +## <a id="issues"></a>Known Issues
> +
> +## <a id="credits"></a>Credits
> +
> +jclouds would like to thank everyone who contributed time and effort in order to make this release happen:
> +
> +* Apache jclouds [PMC](http://people.apache.org/committers-by-project.html#jclouds-pmc) and community for verifying the release.
> +* Check out who has been busy on [Open Hub](https://www.openhub.net/p/jclouds/contributors?query=&sort=latest_commit).
> +
> +## <a id="test"></a>Test Results
> +
> +Please see the [discussion thread](http://markmail.org/thread/lertwftpifagoor3) and the [vote thread](http://markmail.org/thread/lertwftpifagoor3) for test results for 1.8.1.
> +
> +See [this blog post](TODO) for more information on POODLE and jclouds.

Would also be OK with dropping this, and simply publishing the blog as a separate item. Whilst I fully agree that POODLE is not related to 1.8.1 specifically, this _is_ the first release of jclouds after POODLE, so I think it's legitimate to at least reference it. We don't have anything to hide here, in my opinion.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138/files#r19324754

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by Andrew Phillips <no...@github.com>.
> +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.

> In other words, let's please not start picking up responsibility below our abstraction level!

Thanks for all the detailed comments! I'll try to put together an updated version later today. Definitely agree that we want to keep the release notes as short as possible - hence putting this in a blog post, if that wasn't clear.

Text from the release note itself is below:
```
jclouds 1.8.1 and older versions are vulnerable to POODLE since, in the majority of cases, jclouds uses the default JVM SSL settings. [Read more](/blog/2014/10/22/poodle-jclouds/) about the potential impact of POODLE on your jclouds applications and mitigation options.
```
Suggestions for alternatives here?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138/files#r19294424

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by Andrew Phillips <no...@github.com>.
> +  <groupId>org.apache.jclouds.apis</groupId>
> +  <artifactId>openstack-swift</artifactId>
> +  <version>1.8.1</version>
> +</dependency>
> +{% endhighlight %}
> +
> +
> +## <a id="api"></a>API Changes
> +
> +* [openstack-swift API changes from 1.8.0 to 1.8.1](api-changes/openstack-swift/)
> +
> +## <a id="issues"></a>Known Issues
> +
> +* TODO
> +* Since, in the majority of cases, jclouds inherits the default JVM SSL settings, jclouds 1.8.1 (and older versions) are vulnerable to POODLE. [Read more](/blog/2014/10/22/poodle-jclouds/) about the potential impact of POODLE on your jclouds applications and mitigation options.
> +* 1.8.0 includes an [incomplete artifact](http://search.maven.org/#artifactdetails%7Corg.apache.jclouds.labs%7Cgoogle-cloud-storage%7C1.8.0%7Cjar) for Google Cloud Storage. The jclouds team does not recommend its use and 1.8.1 will either complete support or remove this artifact.

@ccustine @abayer Do either of you know whether this is still accurate..?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138/files#r19293165

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by Adrian Cole <no...@github.com>.
> @@ -0,0 +1,73 @@
> +---
> +author: <a href="http://blog.xebialabs.com/author/aphillips/">Andrew Phillips</a>
> +comments: true
> +date: 2014-10-22 23:30:00+00:00
> +layout: post
> +slug: poole-jclouds
> +title: What POODLE means for jclouds
> +---
> +
> +[POODLE](http://googleonlinesecurity.blogspot.com.au/2014/10/this-poodle-bites-exploiting-ssl-30.html) is a recently discovered [man-in-the-middle attack](http://en.wikipedia.org/wiki/Man-in-the-middle_attack) against SSL. If you are communicating via SSL from Java applications, including jclouds 1.8.1 and prior versions, you are potentially vulnerable to this attack.

It takes more than communicating via SSL to be vulnerable to this attack. This sentence betrays the next and creates a context of concern that in most cases is unwarranted.

Look for example at [cocoaspdy](https://github.com/twitter/CocoaSPDY) who discuss a similar attack called CRIME. Rather than get into the weeds, they place responsibility on the user to make their own determination of risk, (eventhough the author is a security expert)! If you replace disable header compression with disable SSLv3, you have a pretty close preamble.

```
CRIME attack

The CRIME attack is a plaintext injection technique that exploits the fact that information can be inferred from compressed content length to potentially reveal the contents of an encrypted stream. This is a serious issue for browsers, which are subject to hijacks that may allow an attacker to issue an arbitrary number of requests with known plaintext header content and observe the resulting effect on compression.

In the context of an application that doesn't issue arbitrary requests, this is less likely to be an issue. However, before you ship a project with header compression enabled, you should understand the details of this attack and whether your application could be vulnerable.
```

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138/files#r19281785

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by Adrian Cole <no...@github.com>.
> +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.

SSLv3 is configured at the http driver layer, typically inherited from their configuration. Jclouds aims to make http drivers configurable without limiting their ability to address this and future TLS issues. Our approach is to document how to use the http drivers in such a way that users can configure them without jclouds intruding on that.

In other words, let's please not start picking up responsibility below our abstraction level!

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138/files#r19283052

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by jclouds-commentator <no...@github.com>.
  Go to http://ae7d8f7be770a72cb0f5-6ef7438193a84a7227bfd1177f7af9b2.r54.cf5.rackcdn.com/ to review your changes.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138#issuecomment-60200065

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by Everett Toews <no...@github.com>.
I took a stab at providing detailed API changes in the release notes for OpenStack Swift. Go to $BASE_URL/releasenotes/1.8.1/api-changes/openstack-swift/ to see them.

Also fixed the error we were seeing earlier. Liquid didn't like the "xx" in the date field.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138#issuecomment-59996478

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by CloudBees pull request builder plugin <no...@github.com>.
[jclouds-site-pull-requests #424](https://jclouds.ci.cloudbees.com/job/jclouds-site-pull-requests/424/) SUCCESS
This pull request looks good

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138#issuecomment-60349761

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by Adrian Cole <no...@github.com>.
> +Many cloud providers are disabling support for SSLv3 - the protocol version exploited by POODLE - on the server-side. Checking whether the cloud providers you are talking to using jclouds have removed support for SSLv3 is the easiest possible fix for you as a user, since it requires no changes to any of your client code.
> +
> +* configure your client code to not support SSLv3 connections
> +
> +See below for options on how to disable SSLv3 support for client applications using jclouds to talk to cloud providers.
> +
> +### Technical details
> +
> +#### How does POODLE relate to jclouds?
> +
> +It is important to note that, except in two specific cases explained below, jclouds does not have any impact on SSL configuration and, specifically, the set of supported SSL protocols. All jclouds HTTP drivers (default, [apachehc](https://github.com/jclouds/jclouds/blob/master/drivers/apachehc/) and [okhttp](https://github.com/jclouds/jclouds/tree/master/drivers/okhttp)) inherit these settings from the JVM.
> +
> +To change the SSL settings for your JVM, and thus the SSL settings that jclouds will use (except in the two cases explained below), create an appropriate [SSLContext](http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLContext.html) and set it as the default socket factory of [HttpsURLConnection](http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/HttpsURLConnection.html):
> +
> +```
> +// Example only! Choose the appropriate SSLContext settings for your scenario!

Note that the following affects the entire JVM.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138/files#r19282442

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by Andrew Phillips <no...@github.com>.
> +jclouds only changes the SSL connection settings (rather than inheriting them from the JVM) in two cases:
> +
> +1) If you are setting `jclouds.trust-all-certs=true`, i.e. are configuring jclouds to trust **all** certificates
> +
> +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

This is the bit I'm least happy with. Can we e.g. try to verify that you don't need to do anything if you're using these two providers: Azure Compute because it probably wasn't working anyway, and FGCP because e.g. SSLv3 is no longer supported on the server-side?

/cc @adriancole @dkoper

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138/files#r19261916

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by CloudBees pull request builder plugin <no...@github.com>.
[jclouds-site-pull-requests #429](https://jclouds.ci.cloudbees.com/job/jclouds-site-pull-requests/429/) SUCCESS
This pull request looks good

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138#issuecomment-60490331

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by Adrian Cole <ad...@gmail.com>.
Sorry I meant distracting not confusing. It is whistling past the graveyard
to use trust-all-certs and have any confidence wrt mitm. Rather than
artificially suggest there is a scenario where this is valid just say.

Prior to jclouds 1.8.2 using trust-all-certs also implies a potential of
SSLv3 use(link to jira with workaround). Regardless, don't use
trust-all-certs if you are concerned with MITM attacks.

The above is far less embarassing for the project.

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by Adrian Cole <no...@github.com>.
> +jclouds only changes the SSL connection settings (rather than inheriting them from the JVM) in two cases:
> +
> +1) If you are setting `jclouds.trust-all-certs=true`, i.e. are configuring jclouds to trust **all** certificates
> +
> +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

It is very, very confusing to spend so much time in the release notes on
trust-all-certs or even fgcp or azure.

Why not just say something simple.

Those who who are using trust-all-certs cannot currently disable SSLv3. If
you need a workaround please contact us.

I don't think we need to discuss labs, but if we did, we could say in a
footnote that those using fgcp and azurecompute are hardcoded to use TLS.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138/files#r19280440

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by jclouds-commentator <no...@github.com>.
  Go to http://a078da31cc53787ae9c9-84efa30bcec2ace12d6bd3dec65f9975.r5.cf5.rackcdn.com/ to review your changes.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138#issuecomment-60505594

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by Andrew Phillips <no...@github.com>.
Merged to [master](https://git-wip-us.apache.org/repos/asf?p=jclouds-site.git;a=commit;h=795753d69eaef5f5a97171c5377c9de993c0736b)

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138#issuecomment-60532934

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by Adrian Cole <no...@github.com>.
> +layout: post
> +slug: poole-jclouds
> +title: What POODLE means for jclouds
> +---
> +
> +[POODLE](http://googleonlinesecurity.blogspot.com.au/2014/10/this-poodle-bites-exploiting-ssl-30.html) is a recently discovered [man-in-the-middle attack](http://en.wikipedia.org/wiki/Man-in-the-middle_attack) against SSL. If you are communicating via SSL from Java applications, including jclouds 1.8.1 and prior versions, you are potentially vulnerable to this attack.
> +
> +<!--more-->
> +
> +Exploiting this vulnerability [is complicated](http://blog.erratasec.com/2014/10/some-poodle-notes.html#.VEb9voBdWIk) and currently requires the attacker to cause many specifically-crafted requests to be executed. It is not clear how this could be achieved if the target user is using jclouds, but the possibility remains, of course.
> +
> +#### What can I do to avoid being affected by POODLE?
> +
> +If you are concerned about POODLE, there are two main ways to avoid being affected:
> +
> +* ensure that your provider no longer supports SSLv3

ex. Check to see if the endpoint you are connecting jclouds to support SSLv3

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138/files#r19281871

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by jclouds-commentator <no...@github.com>.
  Go to http://b1c90eabded8a2ca754d-abce231dea82c6db563d944416e4fa3b.r79.cf5.rackcdn.com/ to review your changes.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138#issuecomment-60490367

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by jclouds-commentator <no...@github.com>.
  Go to http://a989b96f8a7e6c6dc3c9-98845488d1067462a457fd6a2981b7bc.r44.cf5.rackcdn.com/ to review your changes.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138#issuecomment-59994569

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by Adrian Cole <no...@github.com>.
> @@ -0,0 +1,73 @@
> +---
> +author: <a href="http://blog.xebialabs.com/author/aphillips/">Andrew Phillips</a>
> +comments: true
> +date: 2014-10-22 23:30:00+00:00
> +layout: post
> +slug: poole-jclouds
> +title: What POODLE means for jclouds
> +---

General commentary is that we go into way too much detail and dangerously so, since we aren't security experts. This can cause users to get the wrong idea. Considering I can't find any java http client that actually has an official note like this, so we are first to war, and maybe questionably so for reasons discussed earlier.

Oracle, the stewards of the JVM say to [deprecate the use of SSL 3.0 as soon as possible](http://www.oracle.com/technetwork/topics/security/poodlecve-2014-3566-2339408.html), they don't get into the weeds and in fact patches to the JVM and info about them are under a [support firewall](https://support.oracle.com/rs?type=doc&id=1935950.1).

Redhat made some commentary on [disabling on java servers](https://access.redhat.com/solutions/1232233) which can be used for guidance. Note that clearly servers have more at play as they serve browsers, which are the primary attack vector.

If you follow that link, you'll see a blurb on clients eventually.
https://access.redhat.com/articles/1232123

Best advice I can give is do not make up advice, just state facts.

This is a MITM attack (quote oracle or red hat for description). Suggest users assess their level of impact. Note the component responsible, show an *example* of how to affect HttpsUrlConnection, but be clear about who to ask for details (javadoc, oracle, openjdk, etc). Note components or configuration that limit ssl configuration without suggesting things like "trust-all-certs" should ever be used for those concerned with MITM.

Hope this helps.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138/files#r19284835

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by Adrian Cole <no...@github.com>.
> +
> +jclouds only changes the SSL connection settings (rather than inheriting them from the JVM) in two cases:
> +
> +1) If you are setting `jclouds.trust-all-certs=true`, i.e. are configuring jclouds to trust **all** certificates
> +
> +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)

This is super weedy and not the place. Just have them contact jclouds-dev or comment on an existing jira, such as the one for azure compute. We have no place littering this wiki with details on labs providers.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138/files#r19282733

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by jclouds-commentator <no...@github.com>.
  Go to http://adda73bfd30802a06c77-7ab43419ec96fec9828dcbacd72d1deb.r35.cf5.rackcdn.com/ to review your changes.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138#issuecomment-60503961

Re: [jclouds-site] Initial strawman for the 1.8.1 release notes (#138)

Posted by Andrew Phillips <no...@github.com>.
> +
> +## <a id="highlights"></a>Highlights
> +
> +* TODO
> +* Graduation of OpenStack Swift
> +* Lots of API cleanup
> +
> +## <a id="api"></a>API Changes
> +
> +* TODO
> +
> +## <a id="issues"></a>Known Issues
> +
> +* TODO
> +* TODO: A note on POODLE and jclouds 1.8.1
> +* 1.8.0 includes an [incomplete artifact](http://search.maven.org/#artifactdetails%7Corg.apache.jclouds.labs%7Cgoogle-cloud-storage%7C1.8.0%7Cjar) for Google Cloud Storage. The jclouds team does not recommend its use and 1.8.1 will either complete support or remove this artifact.

Does anyone know what the status is here? Has this been addressed in 1.8.1?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/138/files#r19066842