PS as I certainly got into the weeds, just there.. will clarify,
especially as gaul raised valid points.
1. I think the proposed fix is distracting, so wouldn't hold back a
release on that.
2. I don't think it would harm many, if any, if we told folks how to
change jclouds to not use ssl v3
3. I suggested a patch, because I think that we shouldn't hold users
who care about poodle hostage to 1.8.1
...but..
I think this should also work
HttpsURLConnection.setDefaultSSLSocketFactory(patchedOne)
This is probably a better quick fix, since it involves no guice. Not
involving guice means we can reorganize a better long-term solution,
and hopefully make test cases to prove it for all http drivers.
-A
On Mon, Oct 20, 2014 at 4:57 PM, Adrian Cole <adrian.f.c...@gmail.com> wrote:
> Right. So, I think the safest way is to provide the information to
> those who wish to patch for poodle. This limits scope of the change to
> those interested in it, and also fixes those who aren't ready to
> switch to 1.8.1
>
> They would do this.
>
> contextBuilder.modules(..., new AbstractModule() {
> @Override public void configure(){}
> @Provides @Singleton Supplier<SSLContext> unpoodled() {
> return // favorite thing.
> });
>
> done. Problem answered.. scope limited.
>
> We then have bought time to think it through a bit. For example, we
> may want to restructure how the ssl contexts are passed around, or
> address other http clients in a consistent way such that client auth
> based apis can still work. (ex. maybe contextBuilder.sslProtocols)
>
> -A
>
> ----longer part---
>
>
> Apache hc was written not knowing that the default executor does this.
>
> @Inject(optional = true)
> protected Supplier<SSLContext> sslContextSupplier;
>
> https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/JavaUrlHttpCommandExecutorService.java#L80
>
> It started doing that because of FCGP.. Only other api that does
> something similar is azurecompute. These two modify the default ssl
> context to allow client auth and if they can't, bad things happen. It
> interestingly becomes the case that we need to modify the default ssl
> context as a part of addressing poodle!
>
> So, considering most folks don't install apachehc, we could defer
> addressing that, or otherwise hardcoding it. We could suggest that the
> most immediate fix (one that won't break any non-labs stuff), is to
> make this patch.
>
> contextBuilder.modules(..., new AbstractModule() {
> @Override public void configure(){}
> @Provides @Singleton Supplier<SSLContext> unpoodled() {
> return // favorite thing.
> });
>
> This will work for those who must change it, regardless of 1.8.1 or
> not, since all asf releases have the optionally injected ssl context
> supplier.
>
> Also, this limits risk only to those who install it. Remember that
> private cloud may not even run TLS stacks, even if it "should". It
> would totally suck to break folks running tests, etc. if we have a
> choice. Now, since we do know which clouds are "providers" we could
> auto-fix all public cloud services. Just saying that it isn't the case
> that every enterprise will patch all internal servers.
>
> WRT "untrusted" I think it confuses things to patch poodle, yet trust
> all certs :) That's why I suggest rolling back that part.
>
> On Mon, Oct 20, 2014 at 10:27 AM, Andrew Phillips <aphill...@qrmedia.com>
> wrote:
>>> Don't mess with the untrusted one. Fix apachehc later.
>>
>>
>> To be clear: by this, you mean *don't* go for the change in SSLModule in
>> [1]? As far as I understand the code, that is also the "untrusted" context
>> used in ApacheHC - the one that's being modified in [1] is in case the user
>> is *not* looking to trust all certs [2].
>>
>> ap
>>
>> [1] https://github.com/jclouds/jclouds/pull/575/files
>> [2]
>> https://github.com/jclouds/jclouds/blob/enforce-tls/drivers/apachehc/src/main/java/org/jclouds/http/apachehc/config/ApacheHCHttpCommandExecutorServiceModule.java#L114-L119
