[Java 17 Specific Issue] Oxalis-AS4 and oxalis 5.5.0 runs into forbidden signature algorithm when sending Peppol

[post-svejk]

When sending with oxalis-outbound on Java 17 most (if not all) attempts run into:

org.springframework.web.util.NestedServletException: Request processing failed; nested exception is network.oxalis.api.lang.OxalisTransmissionException: Unable to verify document signature.\n\tat
...
java.base/java.lang.Thread.run(Thread.java:833)\n
Caused by: network.oxalis.api.lang.OxalisTransmissionException: Unable to verify document signature.\n\tat 
network.oxalis.outbound.lookup.CachedLookupService.lookup(CachedLookupService.java:73)\n\tat 
no.posten.dpost.peppol.dpi.outbound.oxalis.DpiLookupService.lookup(DpiLookupService.java:48)\n\tat 
network.oxalis.api.lookup.LookupService.lookup(LookupService.java:57)\n\tat 
network.oxalis.outbound.transmission.TransmissionRequestBuilder.build(TransmissionRequestBuilder.java:206)\n\tat 
no.posten.dpost.peppol.dpi.outbound.control.ReceiptTransformer.transformMfReceiptToPeppolDpi(ReceiptTransformer.java:71)\n\tat 
no.posten.dpost.peppol.dpi.outbound.rest.ReceiptController.sendDpiKvittering(ReceiptController.java:100)\n\tat 
...
jdk.internal.reflect.GeneratedMethodAccessor89.invoke(Unknown Source)\n\tat java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)\n\tat 
java.base/java.lang.reflect.Method.invoke(Method.java:568)\n\tat 
org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:205)\n\tat 
...
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006)\n\t... 56 common frames omitted\n
Caused by: network.oxalis.vefa.peppol.security.lang.PeppolSecurityException: Unable to verify document signature.\n\tat 
network.oxalis.vefa.peppol.security.xmldsig.XmldsigVerifier.verify(XmldsigVerifier.java:52)\n\tat 
network.oxalis.vefa.peppol.lookup.reader.BusdoxReader.parseServiceMetadata(BusdoxReader.java:121)\n\tat
network.oxalis.vefa.peppol.lookup.reader.MultiReader.parseServiceMetadata(MultiReader.java:67)\n\tat 
network.oxalis.vefa.peppol.lookup.LookupClient.getPotentiallySignedMetadata(LookupClient.java:139)\n\tat 
network.oxalis.vefa.peppol.lookup.LookupClient.getServiceMetadata(LookupClient.java:81)\n\tat 
network.oxalis.vefa.peppol.lookup.LookupClient.getEndpoint(LookupClient.java:168)\n\tat 
network.oxalis.outbound.lookup.CachedLookupService.load(CachedLookupService.java:79)\n\tat 
... 
network.oxalis.outbound.lookup.CachedLookupService.lookup(CachedLookupService.java:71)\n\t... 74 common frames omitted\n
Caused by: javax.xml.crypto.MarshalException: It is forbidden to use algorithm http://www.w3.org/2000/09/xmldsig#rsa-sha1 when secure validation is enabled\n\tat 
java.xml.crypto/org.jcp.xml.dsig.internal.dom.DOMSignedInfo.<init>(DOMSignedInfo.java:155)\n\tat 
java.xml.crypto/org.jcp.xml.dsig.internal.dom.DOMXMLSignature.<init>(DOMXMLSignature.java:141)\n\tat 
java.xml.crypto/org.jcp.xml.dsig.internal.dom.DOMXMLSignatureFactory.unmarshal(DOMXMLSignatureFactory.java:193)\n\tat 
java.xml.crypto/org.jcp.xml.dsig.internal.dom.DOMXMLSignatureFactory.unmarshalXMLSignature(DOMXMLSignatureFactory.java:148)\n\tat 
network.oxalis.vefa.peppol.security.xmldsig.XmldsigVerifier.verify(XmldsigVerifier.java:45)\n\t... 89 common frames omitted

As far as I understand, this is caused by the receiving access point having the problematic algorithm configured in the metadata.
There may be a workaround in using JDKs older than 17, as the change to forbid the algorithm seems to have arisen there:
https://bugs.openjdk.org/browse/JDK-8261246

Is it possible to allow the old algorithm to coexist with the updated one in OxalisAlgorithmSuiteLoader, at least in an interim period? So that oxalis-outbound can work with both older and newer Oxalis endpoints (assuming that the algorithm change propagates the SML metadata)?

[HegeErdal]

We experience the same issue, and is currently a blocker for updating to oxalis 5.5.0

[aaron-kumar]

Peppol AS4 specification is based on CEF eDelivery AS4 profile - 1.14. Section 3.2.6 in this specification recommend that Signature Algorithm MUST be set to http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 (which we set in OxalisAlgorithmSuiteLoader).

SMP Specification at page#24, line 486/487 says that Signature Method MUST be http://www.w3.org/2000/09/xmldsig#rsa-sha1. Every SMP service provider MUST adhere to these specification until OpenPeppol make required changes in specification to allow both SHA1 and SHA256. Peppol AP software like Oxalis also use these specifications for lookup. Java 17 disabled SHA1 algorithm by default : https://bugs.openjdk.java.net/browse/JDK-8261246 which made it difficult to support OpenPeppol specification with latest java runtime e.g. Java 17. Because of above mentioned constraints we are Not moving ahead with Oxalis Java 17 upgrade until OpenPeppol make required adjustment in specification. Though there is Oxalis plan to support Java 11 LTS in near future.

Now after said that in order to clearly understand your problem, can you please clarify whether Oxalis 5.4.0 was working fine with Java 17 and Oxalis 5.5.0 stopped working? @post-svejk , @HegeErdal? At least, from the description of the problem, it look like Oxalis 5.4.0 was working fine with Java 17. Though as of now, we don't have tests & plan to test Oxalis releases with Java 17.

P.S: It is found that Oxalis 5.5.0 is working fine with Java 8 (supported Java version). Please report if this is Not the case for you.

[post-svejk]

...

Now after said that in order to clearly understand your problem, can you please clarify whether Oxalis 5.4.0 was working fine with Java 17 and Oxalis 5.5.0 stopped working? @post-svejk , @HegeErdal? At least, from the description of the problem, it look like Oxalis 5.4.0 was working fine with Java 17. Though as of now, we don't have tests & plan to test every new Oxalis releases with Java 17.

P.S: It is found that Oxalis 5.5.0 is working fine with Java 8 (supported Java version). Please report if this is Not the case for you.

Yes, Oxalis 5.4.0 works fine on Java 17 for us. But it has vulnerabilities in CXF and WSS4J. It seems there is something in the newer versions of CXF or WSS4J that triggered the algorithm signature error.

[aaron-kumar]

It's WSS4J (xmlsec).

Oxalis 5.4.0 use WSS4J version 2.2.7 which in turn use xmlsec version 2.1.7. Oxalis 5.5.0 use WSS4J version 2.4.1 which in turn use xmlsec version 2.3.0.

If you can check xmlsec release note, Apache XML Security for Java 2.3.0 mention [SANTUARIO-574] - Enable secure validation by default - commit : apache/santuario-xml-security-java@bf85dbe

Can you try if excluding & downgrading xmlsec version work for you?

[HegeErdal]

Only downgrading xmlsec don't work (get an error with wss4j). If I also downgrade wss4j, I get this error:

Caused by: java.lang.NoSuchMethodError: 'void org.apache.wss4j.policy.model.AlgorithmSuite$AlgorithmSuiteType.setAsymmetricSignature(java.lang.String)'
fiks-peppol-aksesspunkt-peppol-service-1 | at network.oxalis.as4.util.OxalisAlgorithmSuiteLoader$OxalisAlgorithmSuite.parseCustomAssertion(OxalisAlgorithmSuiteLoader.java:140)

So this doesn't work unfortunately

[post-svejk]

Only downgrading xmlsec don't work (get an error with wss4j). If I also downgrade wss4j, I get this error:

Caused by: java.lang.NoSuchMethodError: 'void org.apache.wss4j.policy.model.AlgorithmSuite$AlgorithmSuiteType.setAsymmetricSignature(java.lang.String)' fiks-peppol-aksesspunkt-peppol-service-1 | at network.oxalis.as4.util.OxalisAlgorithmSuiteLoader$OxalisAlgorithmSuite.parseCustomAssertion(OxalisAlgorithmSuiteLoader.java:140)

So this doesn't work unfortunately

I get similar results.

[dladlk]

Please take a look at

https://github.com/OxalisCommunity/oxalis/blob/dbfe795607ad2cdd55b4df38b9deb48b9b26eb48/Dockerfile-Java-17#LL5C0-L27C0

maybe it helps.

[HegeErdal]

@aaron-kumar
Hi! I just looked at the newest SMP-specification (from june 2023), and I see here that the required signature method has been changed to SHA-256. I guess this means that the signature method in Oxalis should be changed accordingly so we don't have this problem anymore?

https://docs.google.com/viewer?url=https%3A%2F%2Fdocs.peppol.eu%2Fedelivery%2Fsmp%2FPEPPOL-EDN-Service-Metadata-Publishing-1.3.0-2023-06-05.pdf

Edit: I also see from the (implementation guideline that this has to be implemented by June 1st, and that the receiving AP should have implemented this from December 1st.

[dladlk]

Algorithm http://www.w3.org/2000/09/xmldsig#rsa-sha1 is blocked not by Oxalis, but by Java since something like v.17.

Until 01.06.2024, in order to run on new Java versions starting from 17, you should manually modify java.security on your AP which makes SMP lookup to be able to trust SHA1 signed SMP responses, by deleting lines:

    disallowAlg http://www.w3.org/2000/09/xmldsig#sha1,\
    disallowAlg http://www.w3.org/2000/09/xmldsig#rsa-sha1,\

on jdk.xml.dsig.secureValidationPolicy property.

Since 01.06.2024 you should return them back.

[HegeErdal]

Sure, I understand that I have to include these algorithms again in order to make Oxalis run with java17+ and WSS4J version 2.2.7. It was my understanding that the signature method SHA-1 is used/implemented in Oxalis due to Peppol-specifications, and that this couldn't be changed untill Peppol decided otherwise. However, the links I provided over says that Peppol now wants to change away from SHA1 and start using SHA256, with final date June 1st, but the migration policy says that we can already start implementing it now.
Thus, my question is more related to the timelife of implementing this in Oxalis. Is there a plan to change to SHA-256 so that we don't have to change our local code to allow/start using SHA-1? I'm guessing this is not happening automatically, but is a code-change required in Oxalis itself?

[dladlk]

Oxalis does not limit SHA1 or SHA256 - it is Java core limitation. And there is no possible switch from SHA1 to SHA256, because it is SMP response whose digest is calculated by SHA1...
So there is no need in any code change for Oxalis, as it is Access Point. There is a need in code change of SMP instances to fully switch to SHA256 since June 2024.

[HegeErdal]

Ah, ok, then I understand! So I should ask our SMP-provider if they plan to do the change before June 1st, and not Oxalis. Thank you for the quick reply!