For those who like code...
SSLContext sc = SSLContext.getInstance("TLS");
sc.init(null, null, null);
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
Look ma.. no guice.. no jclouds for that matter either.
We shouldn't block the release; we've already squandered enough time
on this one.
-A
http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/HttpsURLConnection.html#setDefaultSSLSocketFactory(javax.net.ssl.SSLSocketFactory)http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/HttpsURLConnection.html#setDefaultSSLSocketFactory(javax.net.ssl.SSLSocketFactory)
On Mon, Oct 20, 2014 at 5:11 PM, Adrian Cole <adrian.f.c...@gmail.com> wrote:
> 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
