Improve ECFSSLContextFactory.getInstance0(String,String)

[merks]

• Modify the behavior so that getInstance0 returns the SSLContext.getDefault() instance if that instance is the one for the specified protocol and for the specified named provider.

eclipse-platform/eclipse.platform#1690

[eclipse-ecf-bot]

Can one of the admins verify this patch?

[sratz]

I think this is not exactly the right solution.

There is a distinction between

• SSLContext.getDefault() which guarantees the returned context to be initialized.
• SSLContext.getInstance(String[, ...]) which makes no guarantee (*) that the context is initialized

org.eclipse.ecf.core.security.SSLContextFactory wraps this behavior (as a delayed, lazy-loading delegate) in its equivalent API methods.

So the call path
org.eclipse.ecf.core.security.SSLContextFactory.getDefault()
should always just return the default.
The implementation should not delegate to
org.eclipse.ecf.core.security.ECFSSLContextFactory.getInstance0(String, String)
at all.

With eclipse-platform/eclipse.platform#1690 we uncover this discrepancy, because the guarantee (*) above is undefined:

• If nonce calls SSLContext.setDefault(SSLContext), then we are lucky, and all methods
  SSLContext.getDefault(), SSLContext.getInstance(String[, ...])
  do return the internal 'default default' context, and all of them are initialized.
• If once calls SSLContext.setDefault(SSLContext), then
  SSLContext.getDefault()
  and
  SSLContext.getInstance(String[, ...])
  contain different internal engines.

So to sum up,

• I think whenever you call
  SSLContext.getInstance(String[, ...])
  the caller must initialize this context and must not rely on it being initialized implicitly.
• org.eclipse.ecf.core.security.SSLContextFactory.getDefault() should just return SSLContext.getDefault()

[merks]

So to sum up,

* I think whenever you call
  `SSLContext.getInstance(String[, ...])`
  the caller _must_ initialize this context and must not rely on it being initialized implicitly.

* `org.eclipse.ecf.core.security.SSLContextFactory.getDefault()` should just return `SSLContext.getDefault()`

I think this not always true though almost always true because I've already look at this case in the debugger. Here we see the call when the special context has not been set:

In this case, we see there is a call to initialize the context and it would be invalid to try to initialize that context:

This is probably the only case that has been tested given that initialization would seem to be expected in general.

So yes, I think generally one should expect the call creates a new context that needs to be initialized and of course in the case we have our specialized already-initialized content, we really want that to be used and not some new instance and not something initialized differently...

I only did the minimal change to ECF that works for the default case and works for our new case with no deep understanding of the intended use case for creating a new context...

[scottslewis]

I introduced the SSLContextFactory osgi service (currently created and configures in ECF core activation) in order to try to get ECF providers away from existing complexities and insecurities wrt SSLContext.getDefault(), SSLContext.setDefault(SSLContext), and SSLContext.getInstance().

e.g. #174

The intention was that as OSGi services are dynamic (defined at start/runtime) rather than statically defined (i.e. SSLContext.getDefault()/getInstance()/setDefault). That it could be configured dynamically in Eclipse (e.g. on startup) or any other OSGi environment.

FWIW, I had very little input or interaction with the original authors of ECFSSLContextFactory (from IBM at the time) and so can't be much help wrt how/why/use cases driving them other than support of early jvm support of https....which was just getting established.