Community
Participate
Working Groups
Discovered while trying to find cause of issue as discussed here: https://github.com/eclipse/openj9/issues/5629 The following files contain iteration code that loops over the system property https.protocols and select the *first* protocol that succesfully (without exception) initializes instead of the *highest grade* protocol first and backing down: ./framework/bundles/org.eclipse.ecf.ssl/src/org/eclipse/ecf/internal/ssl/ECFSSLServerSocketFactory.java ./framework/bundles/org.eclipse.ecf.ssl/src/org/eclipse/ecf/internal/ssl/ECFSSLSocketFactory.java ./providers/bundles/org.eclipse.ecf.provider.filetransfer.httpclient4/src/org/eclipse/ecf/provider/filetransfer/httpclient4/HttpClientDefaultSSLSocketFactoryModifier.java The consequence of this is that when someone passes for example the parameter -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 The iterators in the files above will first test TLSv1, then TLSv1.1 and finally TLSv1.2. Due to the break statement, they will abort the loop after succesful initialization. In many cases, given the above https.protocols, they will select TLSv1 to interact with the remote site, which actually might support TLSv1.2 also Ideally, the code would refer to an known list of supported protocols, mayhaps associate a score or preference for them and always re-order the list by preference. I'm not sure, but I think standard Java is doing that normally when you specify multiple protocols, somewhere buried in the JRE. Also, an improvement would be to make this code singular, maybe a helper function, to avoid the triple copied implementations.
fixed in commit: https://git.eclipse.org/c/ecf/org.eclipse.ecf.git/commit/?id=cea01f8d7208697190accf1304fb71c1abd198af Fixed by ordering/prioritizing https.protocols and their use for creating SSLContext in org.eclipse.ecf.ssl classes and org.eclipse.ecf.providers.httpclient4 class. Refactored in org.eclipse.ecf.ssl to share a class. Since httpclient4 and org.eclipse.ecf.ssl do not share a common parent bundle ended up duplicating the same logic in org.eclipse.ecf.provider.httpclient4. At least down to 2 impls instead of 3. Thanks for the report.
Hi Scott, quick question: In what release version of ECF will this show up? Will that version of ECF show up in existing Eclipse releases or will it only be available in new versions of Eclipse?
(In reply to Rubin Simons from comment #2) > Hi Scott, quick question: In what release version of ECF will this show up? > Will that version of ECF show up in existing Eclipse releases or will it > only be available in new versions of Eclipse? See answer on this comment: https://bugs.eclipse.org/bugs/show_bug.cgi?id=546894#c3
