Remove org.eclipse.ecf.ssl fragment from ECF filetransfer and Eclipse IDE

[scottslewis]

@merks @tjwatson

Long ago and far away IBM contributed the fragment bundle org.eclipse.ecf.ssl to the ECF project via this bugzilla issue.

As the issue indicates via Eric Li comment: The current behavior for ssl connection is using all the CAs in the jre cacerts file. In order to support self-signed cert or other CA roots. We need a way to wire the certs in the trust engine into ssl handshake process.

And so the o.e.e.ssl fragment uses the Equinox [TrustEngine OSGi service: service class org.eclipse.osgi.service.security.TrustEngine, and equinox implementation class: org.eclipse.osgi.internal.service.security.KeyStoreTrustEngine.

My reading of things is that only this service method: org.eclipse.osgi.internal.service.security.KeyStoreTrustEngine.findTrustAnchor(Certificate[])

is used by the ECFTrustManager (consumer class of the TrustEngine).

This code in o.e.e.ssl is now very long in the tooth, with the java cacerts file contents being totally different from it was 18+ years ago. It's also now debatable whether supporting self-signed certificates (on a https server), which the KeyStoreTrustEngine appears to do, could now or in the future be considered an Eclipse security vulnerability by some Eclipse consumers...especially given the new expectations of https/ssl server-side support (e.g. use of self-signed certificates for public non-tes servers is now ) have changed drastically in the past 18 years.

Another reason to remove the fragment is that when it was originally added, javax.net.ssl did not exist in all JDK profiles, and so was added as a fragment so that it could be loaded at o.e.e core startup. With all recent jdks, this is now unnecessary (javax.net.ssl is in all JREs) and so the use of reflection to run the o.e.e.ssl startup is complicated, unnecessary and confusing.

I propose that o.e.e.ssl be deprecated immediately and ultimately removed from Eclipse (first) and ECF (second).

Also, ECF filetransfer and remote services...which are both dependent on ECF core...supports non-Equinox OSGi client and server frameworks (e.g. karaf, felix, etc). The o.e.e.ssl fragment has a compile-time and runtime dependency on the Equinox-specific TrustEngine, and so it would be desirable to not have to maintain or distribute o.e.e.ssl any longer.

[merks]

Note that on Windows, all the products (SDK and EPP) are using which on Windows supports self-signed certificates that have been added to the Windows certificate store:

-Djavax.net.ssl.trustStoreType=Windows-ROOT
-Djavax.net.ssl.trustStore=NONE

Without this option, only the JDKs cacerts are used and generally self-signed certificates don't work.

I investigate where these breakpoints are hit, and looked at the call hierarchy, but I don't see them being hit when loading an https resource via ECF.

Looking at what's involved in removing, I see the feature at the bottom including that bundle and then other feature importing that feature.

But one of those importing features is in ECF:

And I think p2 will need to continue to use that feature even when the fragment is removed.

So it's a little challenging to even test what the impact of this proposed change will be...

[scottslewis]

``` > > Without this option, only the JDKs cacerts are used and generally self-signed certificates don't work. > > I investigate where these breakpoints are hit, and looked at the call hierarchy, but I don't see them being hit when loading an https resource via ECF. >

Yes I tried a couple myself. It seems likely to me that it depends upon the server cert. Maybe there are none out there would actually trigger the TrustManager. idk

And I think p2 will need to continue to use that feature even when the fragment is removed.

So it's a little challenging to even test what the impact of this proposed change will be...

For testing (and/or early deployment) I can simply comment out (or qualify with a system prop) the code in org.eclipse.ecf core ECFPlugin class that calls into the org.eclipse.ecf.ssl fragment code on startup (/org.eclipse.ecf/src/org/eclipse/ecf/internal/core/ECFPlugin.java:150). That would allow testing even though old (or new) fragment is still present in runtime. The features can then be sorted out later. Please discuss among relevant projects and let me know what the inclination and timing is.

[merks]

I used Oomph to create a development environment with source for ECF, p2, and Oomph. Here I could delete the org.eclipse.ecf.ssl fragment and all the references to it. Then I could launch an installer with only these ECF bundles in it:

With that installer I was able to install from a site with a self-signed certificate, with these options

-Djavax.net.ssl.trustStoreType=Windows-ROOT
-Djavax.net.ssl.trustStore=NONE

I verified that the class is not loading:

So as far as I can tell, that fragment really isn't needed for p2's use of ECF...

FYI @akurtakov @laeubi

I think making potentially problematic changes would be done as soon as possible. I'm hopeful that there won't be problems given the testing I've done.