New security advisories for Apache CXF

Four new security advisories have been disclosed for Apache CXF. They are:

• CVE-2014-0109: HTML content posted to SOAP endpoint could cause OOM errors
• CVE-2014-0110: Large invalid content could cause temporary space to fill
• CVE-2014-0034: The SecurityTokenService accepts certain invalid SAML Tokens as valid
• CVE-2014-0035: UsernameTokens are sent in plaintext with a Symmetric EncryptBeforeSigning policy

Please see the security advisories page of Apache CXF for more information. Users are strongly encouraged to upgrade to the latest releases (2.6.14 and 2.7.11).

XML Security improvements for JAX-RS in Apache CXF 3.0.0

Recently on this blog, I've covered the new streaming XML Security functionality that will be available in Apache Santuario - XML Security for Java 2.0.0. For more information about why to use the new streaming implementation, as well as how to use it, please review the following - XML Signature is covered here,  XML Encryption is covered here, and some memory benchmarks are presented here. This article will cover using the new streaming XML Security implementation with JAX-RS messages in Apache CXF 3.0.0.

Apache CXF has the ability to secure JAX-RS clients and service XML requests with both XML Signature and Encryption, please see the CXF documentation for more information. Given that a new StAX-based XML Security implementation was available via Apache Santuario - XML Security for Java 2.0.0, it was natural to port this to CXF to be used by JAX-RS clients and endpoints. To show how to use the new functionality (as well as the older DOM-based XML Security functionality), I've created a new cxf-jaxrs-xmlsecurity project in github.

1) XML Signature test-cases

The following tests show how to use XML Signature with JAX-RS clients and endpoints:

• XMLSignatureDOMTest - Sign + verify using the (older) DOM API
• XMLSignatureStaxTest - Sign + verify using the new StAX API
• XMLSignatureInteropTest - Test interop between the two implementations

The clients are configured in code, and the service endpoints are configured in spring. The service configuration for the streaming case is here. 

 

2) XML Encryption test-cases

The following tests show how to use XML Encryption with JAX-RS clients and endpoints:

• XMLEncryptionDOMTest - Encrypt + decrypt using the (older) DOM API
• XMLEncryptionStaxTest - Encrypt + decrypt using the new StAX API
• XMLEncryptionInteropTest - Test interop between the two implementations

The clients are configured in code, and the service endpoints are configured in spring. The service configuration for the streaming case is here. 

3) Configuration

The streaming XML Security implementation is configured in a very similar way to the DOM implementation. In the tests above, the same configuration parameters (usernames, keys, callbackhandler, etc.) are passed as properties for both implementations. One difference is that the streaming implementation has a single unified interceptor for both XML Signature and XML Encryption, whereas the DOM code has separate interceptors for both cases.

For the outbound case, the interceptor is XmlSecOutInterceptor. This interceptor
has the following properties that can be configured:

• EncryptionProperties encryptionProperties - An EncryptionProperties Object to use to configure algorithms for encryption.
• SignatureProperties sigProps - A SignatureProperties Object to use to configure algorithms for signature.
• boolean encryptSymmetricKey - Whether to encrypt the symmetric key or not in an EncryptedKey. The default is true.
• SecretKey symmetricKey - A symmetric key to use. If not specified, it is generated randomly.
• boolean signRequest - Whether to sign the request or not. Default is false.
• boolean encryptRequest - Whether to encrypt the request or not. Default is false.
• List<QName> elementsToSign - The QNames of Elements in request to sign. If not specified the entire request is signed.
• List<QName> elementsToEncrypt - The QNames of Elements in request to encrypt. If not specified the entire request is encrypted.
• boolean keyInfoMustBeAvailable - Whether to add a KeyInfo structure or not to the signature/encryption. The default is true.

The inbound interceptor is XmlSecInInterceptor. This has the following properties that can be configured:

• EncryptionProperties encryptionProperties - An EncryptionProperties Object to use to configure algorithms for encryption.
• SignatureProperties sigProps - A SignatureProperties Object to use to configure algorithms for signature. 
• String decryptionAlias - The alias to use to retrieve a private key from the keystore to decrypt the request. If not specified it falls back to the default alias in the Crypto properties file (if specified).
• String signatureVerificationAlias - The alias to use to retrieve a certificate/public key from the keystore to verify the Signature, if the Signature does not contain a KeyInfo with a complete certificate/key.
• boolean requireSignature - Whether the request must be signed. The default is false.
• boolean requireEncryption - Whether the request must be encrypted. The default is false.

4) Some observations

The new streaming JAX-RS XML Security implementation is quite similar in terms of functionality and behaviour to the older DOM implementation. However there are a few differences to note:

• The DOM-based XML Signature implementation supports Enveloped, Enveloping and Detached "styles". The StAX implementation only supports Enveloped.
• The decryption alias must be supplied for the StAX case (or a default alias in the Crypto properties file). The DOM code takes the EncryptedKey and checks for a matching private key in the Crypto properties file. The StAX code expects to be supplied with the matching private key.
• The XmlSecInInterceptor has booleans "requireSignature" and "requireEncryption" which should be set if you want to enforce that a message should be signed and/or encrypted. However, there are some scenarios where the internal interceptor that enforces these requirements may run before security processing has finished. If you are seeing exceptions along these lines, then disable the boolean values, but it is up to you then to retrieve the stored security values and match them against the security requirements.

Apache Santuario - XML Security for Java 2.0.0 - part III

In the previous couple of posts, I've introduced the new streaming functionality of Apache Santuario - XML Security for Java 2.0.0. The first post focused on XML Signature and the second post focused on XML Encryption. This post will discuss the performance of the new streaming approach. In particular, we will focus on the memory consumption of the DOM vs StAX implementations as the size of the XML tree increases. Both implementations are roughly equivalent in terms of timing, however as we will see there is a big different in terms of memory usage.

1) Encryption

Here is a graph that shows the memory consumption of the StAX versus DOM implementations for encryption, as the size of the XML tree grows.

2) Decryption

Here is a graph that shows the memory consumption of the StAX versus DOM implementations for decryption, as the size of the XML tree grows.

3) Signature Creation

Here is a graph that shows the memory consumption of the StAX versus DOM implementations for signature creation, as the size of the XML tree grows. This is the only case where the memory consumption of the streaming code does not remain relatively flat, as some caching is involved in the signature creation case. However, the memory consumption is still substantially less than for the DOM code.

4) Signature Verification

Here is a graph that shows the memory consumption of the StAX versus DOM implementations for signature verification, as the size of the XML tree grows.

5) Conclusion

The new streaming implementation in Apache Santuario - XML Security for Java uses far less memory for large XML trees than the current DOM implementation for XML Encryption and XML Signature verification. It also uses substantially less memory for large XML trees for XML Signature creation. If you are working with large XML trees then you should experiment with the new functionality to see if it improves performance.

Apache Santuario - XML Security for Java 2.0.0 - part II

In the previous blog post, I covered the new StAX-based (streaming) XML Signature functionality coming in Apache Santuario - XML Security for Java 2.0.0. In this post, I will focus on the new streaming XML Encryption functionality that will also be available in this release.

1) XML Encryption test-cases

I have uploaded some test-cases to github to show how to use the new StAX-based API. The tests and setup mirror the XML Signature testcases that I covered in the previous blog post. There are currently three junit tests in this project:

• EncryptionDOMTest - Encrypt + decrypt using the (older) DOM API
• EncryptionStAXTest - Encrypt + decrypt using the new StAX API
• EncryptionInteropTest - Test interop between the two implementations

2) Outbound StAX configuration

To see how to configure the new outbound StAX-based XML Encryption functionality, take a look at the "encryptUsingStax" method used by the tests. The streaming XML Security functionality is configured by populating a XMLSecurityProperties Object. You must typically call the following methods for XML Encryption:

• properties.setAction(XMLSecurityConstants.Action) - an "Action" to perform, which for XML Encryption purposes is XMLSecurityConstants.ENCRYPT. 
• properties.setEncryptionKey(Key) - The encrypting key. Typically a SecretKey instance.
• properties.setEncryptionSymAlgorithm(String) - Symmetric encryption Algorithm to use. The default is AES 256.
• properties.addEncryptionPart(SecurePart) - Add a SecurePart to encrypt, e.g. encrypt a given QName. 
• properties.setEncryptionTransportKey(Key) - The key to use to encrypt the secret key (if desired). Either a SecretKey or PublicKey instance.
• properties.setEncryptionKeyTransportAlgorithm(String) - The encryption key transport algorithm to use, to encrypt the secret key (if desired). Default is RSA OAEP.
• properties.setEncryptionKeyIdentifier(SecurityTokenConstants.KeyIdentifier) - How to reference the encrypting key/cert. The default is SecurityTokenConstants.KeyIdentifier_IssuerSerial.  

The valid Encryption KeyIdentifier types are:

• SecurityTokenConstants.KeyIdentifier_KeyValue
• SecurityTokenConstants.KeyIdentifier_KeyName
• SecurityTokenConstants.KeyIdentifier_IssuerSerial
• SecurityTokenConstants.KeyIdentifier_SkiKeyIdentifier
• SecurityTokenConstants.KeyIdentifier_X509KeyIdentifier
• SecurityTokenConstants.KeyIdentifier_X509SubjectName
• SecurityTokenConstants.KeyIdentifier_NoKeyInfo

3) Inbound StAX configuration

To see how to configure the new inbound StAX-based XML Encryption functionality, take a look at the "decryptUsingStAX" method used by the tests. As with encryption creation, it is necessary to create a XMLSecurityProperties Object, and to tell it what "Action" to perform. In addition you must call the following method:

• properties.setDecryptionKey(Key) - a key to use to decrypt the request.

In addition, it is possible to pass a SecurityEventListener to record what security events were performed (see TestSecurityEventListener used in the tests). This allows the user to check what algorithms were used, what was encrypted etc.