narupley / not-going-to-be-commons-ssl Goto Github PK

Issue that occurs since Mirth Connect ships with bcprov-jdk18on-171.jar

This constructor has been deprecated since a while (also in bcprov-jdk15on) and replaced with static method create

java.lang.IllegalAccessError: class org.apache.commons.ssl.PKCS8Key tried to access method 'void org.bouncycastle.asn1.ASN1OutputStream.(java.io.OutputStream)' (org.apache.commons.ssl.PKCS8Key and org.bouncycastle.asn1.ASN1OutputStream are in unnamed module of loader java.net.URLClassLoader @81d9a72)
at org.apache.commons.ssl.PKCS8Key.encode(PKCS8Key.java:1000)
at org.apache.commons.ssl.PKCS8Key.formatAsPKCS8(PKCS8Key.java:982)
at org.apache.commons.ssl.PKCS8Key.(PKCS8Key.java:212)

Please upgrade the library bcprov-ext-jdk15on to latest one. version 1.60 contains known vulnerabilities.

First of thanks for this port. I have to use a 3rd party library which depends on not yet commons and now I can use it on Java 11!

But when I use the library I get a console message. This suggests it will not work in future Java version...

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.apache.commons.ssl.Java14 (file:/Users/fried/.gradle/caches/modules-2/files-2.1/com.narupley/not-going-to-be-commons-ssl/0.3.18/5bf11e76817939747249e9ff60597cf1e9e0fd45/not-going-to-be-commons-ssl-0.3.18.jar) to method sun.security.ssl.SSLSocketImpl.setHost(java.lang.String)
WARNING: Please consider reporting this to the maintainers of org.apache.commons.ssl.Java14
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

Hi Team ,

i am working on project where we are using spring-security-saml2-core 1.0.10.RELEASE library and this library having not-going-to-be-commons-ssl 0.3.20 as compile dependency.

Now not-going-to-be-commons-ssl 0.3.20 is using commons-httpclient 3.1 which is vulnerable library so i want to upgrade to
httpclient 4.x

https://mvnrepository.com/artifact/commons-httpclient/commons-httpclient

Refer to above url, it mentioned that commons-httpclient artifacts was moved to httpclient 4.x

how i can make use of httpclient in spring-security-saml2-core along with not-going-to-be-commons-ssl, could anyone suggest me.

For our issue, we are using a third party library that requires not yet commons or newly named not going to be commons. Our application can startup in BCFIPS Approved mode and we remove all other security providers and only use BCFIPS provider.
The issue with the code exists within tryJKS method of KeyStoreBuilder. It actually looks at error messages to determine to throw a badpassword exception vs falling thru and returning null. In general this is a very poor implementation as different security providers can supply different error messages. For our situation, BCFIPS puts 'password' in the message where SUN Provider would simply put 'invalid keystore format'. This ultimately stems from the poor implementation of the TrustMaterial class. This class has many constructors which in the end will call KeyStoreBuilder and try to load a PEM format byte array as a key store. When using SUN it ultimately falls through to the CertificateFactory to load the certificates from a stream. Ideally TrustMaterial should have constructors that are very specific to what is being supplied instead of very generic as ultimately most of the constructors end up as a byte array and who knows what the heck bytes are at that point.

Hi Team,

As part of Java17 upgrade when I ran "jdeps -jdkinternals dom4j.jar" I am getting below error:
jdeps -jdkinternals not-going-to-be-commons-ssl-0.3.20.jar
not-going-to-be-commons-ssl-0.3.20.jar -> C:\ca\jdks\jdk1.8.0_241\jre\lib\jsse.jar
org.apache.commons.ssl.Java13 (not-going-to-be-commons-ssl-0.3.20.jar)
-> com.sun.net.ssl.internal.ssl.Provider JDK internal API (jsse.jar)

It is complaining about usage of internal API's.

Please do the needful.

Thanks
Ashok.

When a certificate does not contain a CN a NPE occurs in the build method of the KeystoreBuilder class.

java.lang.NullPointerException: null
at org.apache.commons.ssl.KeyStoreBuilder.build(KeyStoreBuilder.java:195) ~[not-going-to-be-commons-ssl-0.3.20.jar:0.3.20]
at org.apache.commons.ssl.KeyMaterial.(KeyMaterial.java:179) ~[not-going-to-be-commons-ssl-0.3.20.jar:0.3.20]

Happens when getting the CN of the certificate and not checking if it is null or not.

while (keysIt.hasNext() && chainsIt.hasNext()) {
                Key key = (Key) keysIt.next();
                Certificate[] c = (Certificate[]) chainsIt.next();
                X509Certificate theOne = buildChain(key, c);
                String alias = "alias_" + i++;
                // The theOne is not null, then our chain was probably altered.
                // Need to trim out the newly introduced null entries at the end of
                // our chain.
                if (theOne != null) {
                    c = Certificates.trimChain(c);
                    alias = Certificates.getCN(theOne);
                    alias = alias.replace(' ', '_');
                }
                ks.setKeyEntry(alias, key, keyPassword, c);
            }

We are using this library to encrypt a text with a private key and with a public key we are verifying the integrity of the text.
I have attached a zip file, inside resources, I have four files. two private keys and two private keys. The class that runs the project is called SelloSuccessTest.java and SelloFailtureTest.java

If the SelloSuccessTest class is run, the code executes successfully.
mvn test -Dtest=SelloSuccessTest

If the SelloFailtureTest class is run, the code does not run successfully and returns an error.
mvn test -Dtest=SelloFailtureTest
java.lang.IllegalArgumentException: Null input buffer
Collapse

check-sellos.zip

Could you help us?

Actually, security and legal is key aspects of our project. can we use this in production ? I see there is one question raised by Jan 10 and there is no reply on that.

I came here, because we are having a problem with the OpenText Fortify product (previously owned by Micro Focus). This is a commercial product that apparently uses this library. Which of course has me frowned upon, as this is "alpha" code...

Anyway, the issue we're experiencing is that a lot (thousands a day!) of crl*.tmp files get created. The code responsible for creating these files seems to be the CRLHolder.CheckCRL() method in the Certificates class. The CRLHolder class seems to create these CRL temp files as a sort of cache. However, the cleanup of these files apparently fails in some situations. I did a quick inspection of the code and found some problems:

First, in the context of Fortify the tempFile.deleteOnExit(); has little effect. As Fortify is a long-running process, and basically never exits. So these files won't be deleted.

Secondly, and more importantly, the following code seems problematic:

https://github.com/narupley/not-going-to-be-commons-ssl/blob/346bb4e8481316687a643219800a398ecd8f62a8/src/main/java/org/apache/commons/ssl/Certificates.java#L424C21-L426C88

I think this code may throw an IOException, which is caught below. But in this situation, the temp file that was created above it never gets deleted and becomes orphaned. The code on line 432 does delete the temp file. But that code is never reached when the code linked to above is throwing an exception. The IOException handling code on line 439 should probably also contain a tempFile.delete() call.

commons-httpclient version 3.1 has several known vulnerabilities. The artifact is renamed for 4.x and should be used instead

If both CACERTS and JSSE_CACERTS are null, then an NPE occurs at https://github.com/narupley/not-going-to-be-commons-ssl/blob/0.3.20/src/main/java/org/apache/commons/ssl/TrustMaterial.java#L167

Here's an example the stack trace:

java.lang.NullPointerException
        at org.apache.commons.ssl.TrustMaterial.<init>(TrustMaterial.java:167)
        at org.apache.commons.ssl.TrustMaterial.<init>(TrustMaterial.java:158)
        at org.apache.commons.ssl.TrustMaterial.<clinit>(TrustMaterial.java:148)
        at org.opensaml.xml.security.x509.X509Util.decodeCertificate(X509Util.java:359)

Bouncycastle provides the artifacts bcprov-jdk15on and bcprov-ext-jdk15on, where the ext is a superset of the non-ext artifact, so depending on both is pointless. As the only difference currently seems to be the NTRU algorithm (see http://bouncycastle.org/latest_releases.html), I would suggest to just depend on the non-ext artifact and users who need that algorithm can do the song-and-dance to switch out the dependency.