PS for the sake of documentation, POODLE only affects servers who
respond to sslv3. In other words jclouds users don't need to worry if
they only use hosts that don't respond to below.
echo|openssl s_client -connect $DOMAIN:443 -ssl3 2>&1|grep 'ssl
handshake failure'>&-||echo $DOMAIN should disable SSLv3
-A
On Tue, Oct 21, 2014 at 7:56 AM, Adrian Cole <adrian.f.c...@gmail.com> wrote:
> 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
