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
