Implement PKCS

[JavaJoeS]

Add PKCS12 and PKCS11 implementation.
See; eclipse-m2e/m2e-core#1538

[JavaJoeS]

@laeubi @mickaelistria @eclipse-platform-bot Greetings, I have close to 100 downloads of org.eclipse.core.pki from marketplace. Must be doing something right? How about reconsidering loading into platform.. Best regards,
joe

[laeubi]

Its all over the place in a variety of usages and some step on other code, i.e. SSLContext default. I see some TLSv1 code still in the hopper.. [...] Im just trying to help the community. [...]

The please go a ahead and follow this document here

https://github.com/eclipse-platform/.github/blob/main/SECURITY.md

to provide details for a responsible disclosure of this security issues you see in "EPP, P2, MPC, BND, and more" .

[JavaJoeS]

Instead of you trying to derail my pki implementation, as a senior eclipse contributor, you should be asking me how you can be of assistance to me and help me get PKI contributed? Why the sidestep?

[laeubi]

I gave you multiple hints, multiple times (e.g. this still don't contain a readme describing in a clear and consistent way the goals and principles of the implementation), but you are always reiteration of "everything is broken we need (my) PKI" without given any evidence and instead trying at different places (what makes it even harder to follow the discussion..

So I gave you yet another hint now to actually at least report this brokenness of eclipse/platform/... but it seems again I could not be of any help.

[JavaJoeS]

Your "hints" are not of any value to help me get my pki implementation installed. I do not wish to report any bugs. My goal is to add value and make something available in eclipse that is NOT currently available.

[akurtakov]

Your "hints" are not of any value to help me get my pki implementation installed. I do not wish to report any bugs. My goal is to add value and make something available in eclipse that is NOT currently available.

IMO this comment is going against https://www.eclipse.org/org/documents/Community_Code_of_Conduct.php (e.g. "Being respectful of differing viewpoints and experiences;
Gracefully accepting constructive criticism; ").
People that want to contribute are expected to very explicit in what they fix/how they fix/where they fix it and etc. and provide this information thoroughly whenever a committer requests it!
Unless, you provide this information (what exactly is broken in eclipse with an issue(cve if needed!), how you fix this problem exactly and etc.) please stop opening new and new issues/prs/discussions as they lead to no where as so far there is not a single exact problem in Eclipse pointed thus this code (#1716) proves no benefit for the project.

This statement is on behalf of Eclipse PMC (https://projects.eclipse.org/projects/eclipse/who) where this has been discussed multiple times.

[JavaJoeS]

In light of the updates coming out of the Cyber Resilience Act I think we should reconsider adding my pki to eclipse.platform.
Better to have it and not use it than to need it and not have it! Other folks besides me are running into many issues resulting
from bad instances of SSLContext.

[iloveeclipse]

Could you please elaborate how Cyber Resilience Act is related to pki and why eclipse.platform would need that.

[JavaJoeS]

IM not a lawyer nor legal expert. I do have lots of eclipse related security expertise. If you read through lots of the eclipse packages discussions you will find a lot of issues relating to httpclient and specifically the SSLContext. Too many different packages, too many different designs and lots of different versions of same apache software.
My point is; its better to have a security package that can be implemented at a higher level than to have NONE, or current implementations that dont work or cause problems. When I read the Cyber Resilience Act as a lay person, I get the impression that negligence could be construed as a violation. Again, Better to have SECURITY and not use it than to not have it at all. My package is benign if not used. However, if configured properly you get a valid SSLContext. See ECF now has a SSLContextFactory.. That factory accepts a default SSLContext.

[JavaJoeS]

BTHY, would you be willing to help me to get my PKI package into a PR that can be accepted/approved?

I just completed about a miriad of Junit tests.
Constructor MainTest
SecurityFileSnapshot TESTING:eclipse.core.pki.testing
Running org.eclipse.core.tests.pki.auth.ContextObserverTest
OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.721 s -- in org.eclipse.core.tests.pki.auth.ContextObserverTest
org.eclipse.core.tests.pki.auth.ContextObserverTest.testOnChange -- Time elapsed: 0.059 s
Running org.eclipse.core.tests.pki.MainTest
Constructor MainTest
Constructor MainTest
Constructor MainTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.270 s -- in org.eclipse.core.tests.pki.MainTest
org.eclipse.core.tests.pki.MainTest.testRun -- Time elapsed: 0.240 s
org.eclipse.core.tests.pki.MainTest.testPkiPasswordGrabberWidget -- Time elapsed: 0.011 s
org.eclipse.core.tests.pki.MainTest.testSecurityFileSnapshot -- Time elapsed: 0.009 s
Running org.eclipse.core.tests.pki.SecurityOpRequestTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.049 s -- in org.eclipse.core.tests.pki.SecurityOpRequestTest
org.eclipse.core.tests.pki.SecurityOpRequestTest.testRun -- Time elapsed: 0.038 s
org.eclipse.core.tests.pki.SecurityOpRequestTest.testSecurityOp -- Time elapsed: 0.010 s
Running org.eclipse.core.tests.pki.auth.EventConstantTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.051 s -- in org.eclipse.core.tests.pki.auth.EventConstantTest
org.eclipse.core.tests.pki.auth.EventConstantTest.testEventConstantClose -- Time elapsed: 0.044 s
org.eclipse.core.tests.pki.auth.EventConstantTest.testEventConstantSetup -- Time elapsed: 0.002 s
org.eclipse.core.tests.pki.auth.EventConstantTest.testEventConstantDone -- Time elapsed: 0.002 s
Running org.eclipse.core.tests.pki.auth.IncomingSystemPropertyTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.050 s -- in org.eclipse.core.tests.pki.auth.IncomingSystemPropertyTest
org.eclipse.core.tests.pki.auth.IncomingSystemPropertyTest.testCheckTrustStoreType -- Time elapsed: 0.041 s
org.eclipse.core.tests.pki.auth.IncomingSystemPropertyTest.testCheckTrustStore -- Time elapsed: 0.002 s
org.eclipse.core.tests.pki.auth.IncomingSystemPropertyTest.testCheckKeyStore -- Time elapsed: 0.002 s
org.eclipse.core.tests.pki.auth.IncomingSystemPropertyTest.testCheckType -- Time elapsed: 0.001 s
Running org.eclipse.core.tests.pki.auth.KeystoreSetupTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 s -- in org.eclipse.core.tests.pki.auth.KeystoreSetupTest
org.eclipse.core.tests.pki.auth.KeystoreSetupTest.testgetInstance -- Time elapsed: 0.045 s
Running org.eclipse.core.tests.pki.auth.PKISetupTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.235 s -- in org.eclipse.core.tests.pki.auth.PKISetupTest
org.eclipse.core.tests.pki.auth.PKISetupTest.testsetSSLContext -- Time elapsed: 0.220 s
org.eclipse.core.tests.pki.auth.PKISetupTest.testRun -- Time elapsed: 0.001 s
org.eclipse.core.tests.pki.auth.PKISetupTest.testlog -- Time elapsed: 0.001 s
org.eclipse.core.tests.pki.auth.PKISetupTest.testStart -- Time elapsed: 0.001 s
org.eclipse.core.tests.pki.auth.PKISetupTest.testStop -- Time elapsed: 0.002 s
org.eclipse.core.tests.pki.auth.PKISetupTest.testgetInstance -- Time elapsed: 0.002 s
org.eclipse.core.tests.pki.auth.PKISetupTest.testgetSSLContext -- Time elapsed: 0.001 s
org.eclipse.core.tests.pki.auth.PKISetupTest.testStartup -- Time elapsed: 0.002 s
Running org.eclipse.core.tests.pki.auth.PKIStateTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 s -- in org.eclipse.core.tests.pki.auth.PKIStateTest
org.eclipse.core.tests.pki.auth.PKIStateTest.testSetPKCS11on -- Time elapsed: 0.003 s
org.eclipse.core.tests.pki.auth.PKIStateTest.testSetPKCS12on -- Time elapsed: 0.001 s
Running org.eclipse.core.tests.pki.auth.ProxiesTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.083 s -- in org.eclipse.core.tests.pki.auth.ProxiesTest
org.eclipse.core.tests.pki.auth.ProxiesTest.testProxiesUserDomain -- Time elapsed: 0.074 s
org.eclipse.core.tests.pki.auth.ProxiesTest.testProxiesUserName -- Time elapsed: 0.001 s
org.eclipse.core.tests.pki.auth.ProxiesTest.testProxiesWorkstation -- Time elapsed: 0.001 s
org.eclipse.core.tests.pki.auth.ProxiesTest.testProxiesProxyHost -- Time elapsed: 0.002 s
org.eclipse.core.tests.pki.auth.ProxiesTest.testProxiesProxyUser -- Time elapsed: 0.001 s
org.eclipse.core.tests.pki.auth.ProxiesTest.testProxiesProxyAuthentication -- Time elapsed: 0.001 s
org.eclipse.core.tests.pki.auth.ProxiesTest.testProxiesProxyPassword -- Time elapsed: 0.001 s
Running org.eclipse.core.tests.pki.auth.PublicKeySecurityTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.039 s -- in org.eclipse.core.tests.pki.auth.PublicKeySecurityTest
org.eclipse.core.tests.pki.auth.PublicKeySecurityTest.testGetpkiPropertyFile -- Time elapsed: 0.039 s
Running org.eclipse.core.tests.pki.auth.PublishPasswordUpdateTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046 s -- in org.eclipse.core.tests.pki.auth.PublishPasswordUpdateTest
org.eclipse.core.tests.pki.auth.PublishPasswordUpdateTest.testPublishPasswordUpdate -- Time elapsed: 0.043 s
org.eclipse.core.tests.pki.auth.PublishPasswordUpdateTest.testRun -- Time elapsed: 0.002 s

Results:

Tests run: 34, Failures: 0, Errors: 0, Skipped: 0

[iloveeclipse]

BTHY, would you be willing to help me to get my PKI package into a PR that can be accepted/approved

I'm too far from security/SSL business, sorry

[HannesWell]

After reading through the pdf-file you provided as well as some of the issues/PRs at ECF and P2 and some private discussions with others I hope that I have now a basic understanding what you are trying to do. I try to summarize it, but correct me if I'm wrong:
The main scenario we are talking about is for example creating secured network connections, e.g. if one reads the InputStream of a https-URL, or the creation of a corresponding secured (TLS/SSL) Socket connection. And for these cases you want to add means to customize the SSLContext in order to inject other certificates than the ones included into the JDK by default, don't you?

What I'm not sure about: You are talking about Public Key Infrastructure (PKI), but aren't PKI key-pairs something different then TLS/SSL-certificates respectively than the certificates used to verify code-signatures (I assume they are similar to TLS/SSL-certificates)?

In the discussion it was also mentioned that there should be (or is already in ECF?) an OSGi service interface defined where extra certificates can contributed. But from what you have said here and described in your PDE I'm not sure if this is still the goal.
But if that's a/the goal I think this will open the door for big security-issues as every bundle in an Eclipse installation could then implement and register this service and contribute own, potentially malicious certificates. And this could happen without any notice to the corresponding user, because any bundle can contribute any service all the time, without any need to 'announce' that publicly.
So this would be problematic for the same reason why for example the dynamic loading of java agents is problematic and will be disallowed in the future (see JEP 451). In general the goal of the JDK is integrity by default (see draft JEP 8305968) and adding such service to Eclipse would undermine that goal.

Furthermore I also wonder why the existing capabilities of the JDK are not sufficient?
One can import own certificates into the JVM's cacerts-keystore (e.g. https://www.baeldung.com/java-import-cer-certificate-into-keystore) and on Windows Eclipse already uses the OS's trust-store by default as of eclipse-platform/eclipse.platform.releng.aggregator#929 (similar to browsers for example). So at least for Windows there is already a central place that all JVMs can refer to.
Alternatively one can specify in the eclipse.ini to use another cacerts-trust-/keystore file by specifing the VM-argument
-Djavax.net.ssl.trustStore=/path/to/another/truststore.p12:
https://www.baeldung.com/java-custom-truststore
Setting the latter can even be automated using the Eclipse Oomph Installer and defining a corresponding Eclipse Ini task in the user-setup.

What still could be a good addition to Eclipse is UI support, e.g. in the preferences, to import own certificates into the JVMs trust-store or to use a trust-store at an alternative location. This would just execute the steps from the linked tutorials, but a UI would be more convenient.

But in general I think it's better to use the standard ways the JDK provides as much as possible. The JDK has the security-experts and developers need to work on such topics, many more than Eclipse and therefore I think it's better to rely on what they provide.
That being said, if you think that regarding PKI the JDK is missing features I think it's best to suggest it directly to the Open-JDK:
https://openjdk.org/

[JavaJoeS]

The SSLContext may be used to secure a network connection by using the Java cacerts truststore, yes.
This capability is in some of the Eclipse bundles/packages already, except in some packages, not working.
Yes, you can add Certificates to cacerts in your jdk. Currently no way to do this using eclipse.

Whats different about what I am proposing is that not only the ability to add a custom truststore, which
is what you can do already by adding to JDK cacerts, but also add a custom keystore.
Some eclipse packages/bundles attempt to create an SSLContext, but ONLY set the TRUSTSTORE in the SSLContext.

My bundles allow for an SSLContext to be set with BOTH KEYSTORE and TRUSTSTORE.
In turn that allows for a secure httpclient, sockets, etc.

The Keystores I am supporting are PKCS11 and PKCS12. Both of these use X509 Certificates.
I have a PKI UI that allows a user to specify a custom KEYSTORE and a Custom TRUSTSTORE, respectively.
OR for headless systems the required properties can be specified. As you said using -Djavax.net.ssl.trustStore=/path/to/another/truststore along with all the other properties used for SSLContext to be set. I also support a file
to set these properties along with a template to help set them.

THE HUGE issue that is perplexing is that there can be only ONE SSLContext default and as soon as
code sets it, then it overwrites any perfectly good SSLContext that may have been previously set.

JEP451 is for dynamic agents. Nothing to do with what I have.

[HannesWell]

My bundles allow for an SSLContext to be set with BOTH KEYSTORE and TRUSTSTORE.

With TRUSTSTORE you mean e.g. the store built-in Windows?

THE HUGE issue that is perplexing is that there can be only ONE SSLContext default and as soon as
code sets it, then it overwrites any perfectly good SSLContext that may have been previously set.

So one unique-selling point of your plugins is that one can use the JVM's cacert or an alternative file together with the OS' builtin truststore?

The Keystores I am supporting are PKCS11 and PKCS12

Just for clarification the JVM also supports them by default? But just a single file?

Yes, you can add Certificates to cacerts in your jdk. Currently no way to do this using eclipse.

Adding support for just importing certificates into the cacerts file of the running JVM is something that I think would be useful and shouldn't be a too big feature to implement.
The best location would probably be the preference about network-connections:

Other good and not big features could be a UI to change to the OS builtin truststore or to add an UI that allows an inspection of the available certificates of the store in use (or maybe even another file currently not in use).

All of these could be independent features/PR and would basically add a UI to set the configuration options the JDK provides by default.
Then one could still use only one store at the time, but having a UI to switch it (probably after a restart) or to extend it would certainly help most users.

#1716

JEP451 is for dynamic agents. Nothing to do with what I have.

Yes, I know. :) It was just a reference to give an example for the idea of my previous point.

[JavaJoeS]

BTHY, I have lots of companies using my product already, 100's of people. World Wide. The problem is: Every time a new version
is released I have to make changes to make SSLContext work. Then I have to distribute it. Giving my product a home would go a long way to make our Eclipse product better.

[JavaJoeS]

In addition to Eclipse, I have done the same value adds to Gradle, Maven, and M2E. ALL performing Secure network connections.
SO many companies want their artifacts secure now with so much hacking going on.

[akurtakov]

Please whenever you have such claims please point to the commits in Gradle, Maven, etc. that have been accepted!

[JavaJoeS]

I have not given back yet to any project, Eclipse was first on my giveback list. Eclipse is my favorite! PR Submitted.

[akurtakov]

Closing as there is PR which awaits clear action from contributor and communication should be handled in less places. #1716 (comment)