Kindof thinking this should have been on the discuss thread.. Anyway, the critical part of testing any patch is validating that sslSocket.getEnabledCipherSuites() does not contain "SSLv3", or.. a test server otherwise proves it.
The testing part might be a bugger, as not all servers allow you to control this (MockWebserver can). Regardless, there are many ways to assert this. Bottom line, I'd hesitate to offer any patch (particularly shotgun ideas) before a test proves is is correct, and this thread absolutely is hijacking the release as the scope is all jclouds versions. -A http://docs.oracle.com/javase/6/docs/api/javax/net/ssl/SSLSocket.html#getEnabledCipherSuites() 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
