MG>below ________________________________ From: Jesper Duelund Isaksen <[email protected]> Sent: Thursday, July 11, 2019 3:17 AM To: [email protected] Subject: RE: Alternative to Merlin crypto provider
Hi Martin I might have used the TLSClientParameters example imprecisely. I focused primarily on the API exposing the ability to set the arrays of KeyManagers and TrustManagers directly. Please do correct me if I’m wrong, but as far as I know WSS4J primarily deals with KeyStores and TrustStores in relation to doing message-level encryption, signing, decryption and signature verification. It is not my understanding that WSS4J actually works with sockets. We are expecting to create a crypto provider similar to org.apache.wss4j.common.crypto.CertificateStore except it should also be able to handle encryption and signing. However it sounds like you have a broader perspective on this? MG>keep in mind cerificates != keyStore(s) != trustStore(s) MG>you ALWAYS need keyStores MG>private and public for assymetric MG>shared key for symmetric https://www.ssl2buy.com/wiki/symmetric-vs-asymmetric-encryption-what-are-differences MG>you need TrustStore to validate Other CA Certs (external clients presenting a CA Cert to you) https://www.java67.com/2012/12/difference-between-truststore-vs.html MG>CertificateStore is WSS4J store for array of X509 Certs notice the doc: /** * A Crypto implementation based on a simple array of X509Certificate(s). * Private Keys are NOT supported * so this cannot be used for signature creation, or decryption. */ MG>this is the reason why I think implementing your own SSLSocketFactory is the way to go MG>(because of the baked-in support for getTrustManagers() and getKeyManagers() and getJsseProvider() and getCipherSuites() ) MG>but there are specifics of the crypto you are developing we need to understand to see if it 'fits' into existing infrastructure MG>mainly which specific algos will you be supporting MG>currently WSS4J CertificateStore supports ONLY these cryptoType(s) * TYPE.ISSUER_SERIAL - A certificate (chain) is located by the issuer name and serial number * TYPE.THUMBPRINT_SHA1 - A certificate (chain) is located by the SHA1 of the (root) cert * TYPE.SKI_BYTES - A certificate (chain) is located by the SKI bytes of the (root) cert * TYPE.SUBJECT_DN - A certificate (chain) is located by the Subject DN of the (root) cert * TYPE.ALIAS - A certificate (chain) is located by an alias. In this case, it duplicates the * TYPE.SUBJECT_DN functionality. MG>does your new crypto conform to one of the above types? Thanks for the support! I hope we can create something useful. Kind regards Jesper MG>it is amazing how much work the folks at BouncyCastle put in to positively assert their cryptos work in JSSE From: Martin Gainty <[email protected]> Sent: 10. juli 2019 19:23 To: [email protected] Subject: Re: Alternative to Merlin crypto provider a great idea for expanding WSS4Js capability to handle other crypto providers! if you're in TLSClientParameters take a look at: /* Returns whether or not {@link javax.net.ssl.HttpsURLConnection#getDefaultSSLSocketFactory()} should be * used to create https connections. If <code>true</code> , {@link #getJsseProvider()} , * {@link #getSecureSocketProtocol()}, {@link #getTrustManagers()}, {@link #getKeyManagers()}, * {@link #getSecureRandom()}, {@link #getCipherSuites()} and {@link #getCipherSuitesFilter()} are * ignored. */ theoretically your new implementation of SSLSocketFactory once set thru tlsClientParameters.setSSLSocketFactory(JesperSSLSocketFactory) would 'provide' the necessary requisite attributes: JsseProvider TrustManagers KeyManagers /* some helpful Info from JSSE doc page: */ Obtaining an SSLSocketFactory There are three primary ways of obtaining an SSLSocketFactory: · Get the default factory by calling the SSLSocketFactory.getDefault static method. · Receive a factory as an API parameter. That is, code which needs to create sockets but which doesn't care about the details of how the sockets are configured can include a method with anSSLSocketFactory parameter that can be called by clients to specify which SSLSocketFactory to use when creating sockets. (For example, javax.net.ssl.HttpsURLConnection.) · Construct a new factory with specifically configured behavior. The default factory is typically configured to support server authentication only so that sockets created by the default factory do not leak any more information about the client than a normal TCP socket would. Many classes which create and use sockets do not need to know the details of socket creation behavior. Creating sockets through a socket factory passed in as a parameter is a good way of isolating the details of socket configuration, and increases the reusability of classes which create and use sockets. You can create new socket factory instances either by implementing your own socket factory subclass or by using another class which acts as a factory for socket factories. One example of such a class is SSLContext, which is provided with the JSSE implementation as a provider-based configuration class. once coded your new crypto provider would be specifed in $JRE_HOME/lib/security/java.security as security.provider.1 ? https://doc.bccnsoft.com/docs/jdk7-docs/technotes/guides/security/jsse/JSSERefGuide.html#SSLSocketFactory is this you're thinking? i support your efforts in expanding crypto providers for WSS4 and would like to help this important effort any way i can M- ________________________________ From: Jesper Duelund Isaksen <[email protected]<mailto:[email protected]>> Sent: Tuesday, July 9, 2019 7:22 AM To: [email protected]<mailto:[email protected]> Subject: RE: Alternative to Merlin crypto provider Thanks for the very quick reply! Alright, so a custom provider is the way to go. We are only experimenting at the moment so I am unsure if we will get to the point of having something good enough for contribution. The SVN repository is the correct place to branch out a separate contribute I assume? Kind regards Jesper From: Colm O hEigeartaigh <[email protected]<mailto:[email protected]>> Sent: 9. juli 2019 10:12 To: [email protected]<mailto:[email protected]> Subject: Re: Alternative to Merlin crypto provider Contributions to the project involving new Crypto implementations would be very welcome :-) Colm. On Tue, Jul 9, 2019 at 8:02 AM Jesper Duelund Isaksen <[email protected]<mailto:[email protected]>> wrote: Hi Does anyone know if an alternative to Merlin already exists that allows configuring Apache WSS4J with in-memory KeyStores, KeyManager and TrustManager or similar? Perhaps something similar to what is exposed in CXF using the org.apache.cxf.configuration.jsse.TLSClientParameters class? We experimenting with a common security library implementation on top of Apache CXF for a set of services with a common WS-Trust-like security model intended to be running in containers. It would be great if secrets could be fetched from a system like HashiCorps Vault or similar, however this seems to conflict with using static JKS keystores for the WSS4J configuration. Alternatively it would perhaps be an idea to implement a custom crypto provider? Are there any critical pitfalls to be aware of, if this the way to go? Kind regards Jesper Duelund Isaksen -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
