This article is written for security or network specialists and a certain level of security expertise is assumed.
By default, PaperCut is configured to support a wide variety of SSL ciphers with the aim of supporting the widest array of browsers and operating systems possible. When a client connects to the server, the two communicate and pick the best/most secure cipher that the two mutually support. Some organizations may choose to disable some ciphers on the server-side to comply with policies such as PCI-DSS recommendations. Reducing the available ciphers may limit the support for older browsers, however this may not be a concern in a standardized and up-to-date environment.
An often asked question is how to control and fine tune SSL cipher lists in use by the PaperCut application server.
This question may arise in response to the desire of continuously reviewing and strengthening security infrastructure and ciphers in use in any particular deployment (such as mitigating potential attack via the BEAST SSL vulnerability CVE-2011-3389) or in order to implement a security policy such as support for Perfect Forward Secrecy in TLS communications.
In future versions of PaperCut we may make the decision to remove some of the default ciphers.
The configuration process is different depending on PaperCut version thatís in use.
Perfect Forward Secrecy
One other security concept worth discussion is operating in “Perfect Forward Secrecy” mode (PFS), to achieve this all communications should be based on PFS based cipher suites. These cipher suites are special in the sense that they split off the responsibility of mutual authentication and key exchange that occurs in an SSL handshake over to multiple sets of cryptographic keys.
This means that only a subset of data sent between two points is vulnerable at any given time as a different key is used for each session as opposed to all of the communications that may have occurred if say the RSA key was used for both authentication and key exchange. This comes at some processing cost however. Furthermore the session key is not transmitted or saved so will not be available to recovery from a hard drive for example.
In order to accomplish this it is required to cull the list of cipher suites quite dramatically and only allow those that are based on DHE and ECDHE families. These correspond to Diffie-Hellman with ephemeral keys and DHE based on elliptic curve cryptography.
Having only forward secrecy compliant cipher suites enabled you have achieved forward secrecy in TLS handshakes but the degree of that secrecy varies as some forward secrecy ciphers can still use weaker keys. Java places a few limitations on DH key sizes still (locked to 768-bits).
Something to keep in mind is currently it’s not possible to to define a preferred cipher order on the server side so while the chosen cipher will be selected from the cut down list, which one will depend on the client connecting to the server at least to some degree.
In summary PFS operation mode can be achieved but with varying degree of strength and tinkering is required. The number of potentially compatible clients will also decrease as the cipher suites are reduced.
SSL/TLS and MFDs
In addition to connections between web clients and the PaperCut application server in PaperCut MF we have to interface with various copiers and devices created by third parties. The cryptographic technology on these devices varies and sometimes lags behind current best practice. In some extreme cases this means that we cannot simply increase various security parameters such as certificate key sizes, signature algorithms and allowed SSL ciphers across the board without breaking communication with these devices.
Currently we offer these notes as guidance on how to lock down and fine tune the secure communications, with a word of caution on potentially breaking compatibility with other applications. Thorough testing is strongly recommended and the results will vary based specific fleet of devices, models and firmware versions in use.
Version 14 and above
As of PaperCut version 14.0 we have upgraded the underlying runtime to Java 7.
This offers improved flexibility when trying to accomplish the goals of precise control over the use of ciphers and applies globally to the JVM without needing to configure the Jetty web server. This applies to inbound communications. In addition Java 7 also offers TLS 1.2 support.
The Java 7 platform now provides a user facing mechanism that allows cipher suites to be excluded from use via a security policy file called
java.security thatís located under Java Runtime Environment in the
PaperCut places its Java Runtime under
[app-path]/runtime folder with minor variation due to system specifics, eg:
[app-path]/runtime/win64/jre on 64 bit Windows for example and
[app-path]/runtime/jre on 32 bit.
Note that currently customizations are not kept across upgrades and any changes will need to be reapplied.
The policy file defines the
jdk.tls.disabledAlgorithms property to control TLS cipher selection. There is also a complementary property
jdk.certpath.disabledAlgorithms to control algorithms encountered in SSL certificates.
You can find the documentation for this property on the Oracle website:
JSSE Reference Guide
As an example the following more secure policy default can be applied:
jdk.tls.disabledAlgorithms=MD5, SHA1, DSA, RSA keySize < 2048
This means: no MD5, no SHA1, no DSA. RSA is allowed only if the key is at least 2048 bits long.
This property can be customized to further tailor a site deployment to specific needs.
For example as a starting point ďexportĒ strength ciphers as well as DES/3DES and MD5 based cipher suites can be removed.
To improve the security of the allowed ciphers it’s possible to disallow SHA1 and RC4, however this may come at the cost of breaking compatibility with some Windows XP based software (eg Windows XP itself didnít include SHA2 support by default until Windows XP SP3).
One can find all the cipher suites enabled by default in Java 7 here: Default Cipher Suites in Java 7 (unless the default SunJSSE crypto provider has been explicitly overridden and is not used).
Please note that if AES-256 encryption is selected then this will also require obtaining “Unlimited Strength Jurisdiction Policy files” from the Oracle Java Download Page
We have developed a plugin that will allow configuration of the cipher list in older versions of PaperCut (version 11 through 13). The plugin configures connections at the Jetty (embedded HTTP server and servlet engine).
The PaperCut plugin architecture has been utilized to deliver an immediate solution for all versions of PaperCut back to version 11. The advantage of taking this plugin approach is that it allows sites to modify the cipher list immediately without the need to schedule an upgrade of an operation production system. The plugin can be applied to any edition of PaperCut with minimal impact, functional change risk, and downtime.
It is intended that an experienced system administrator install and configure this plugin, with careful testing required after implementation. Download the plugin Jetty Config Plugin here: jetty-config-plugin-v1.zip.
Unzip the contents; installation and configuration steps are outlined in the
README-JETTY-CONFIG.txt. In summary, the process will involve:
- Copy the following files to
- Open the
jetty-config-plugin.properties file in your preferred text editor and append the list of ciphers to exclude. Save the file.
- Restart the PaperCut Application Server service and re-test with an appropriate security scanning tool.
TIP: After installing the plugin, the list of ciphers supported by your server will be reported in the
[app-path]\server\logs\server.log file at startup. This list may be used to identify the name of included and excluded ciphers.
This is a complex topic and the security-focused team at PaperCut Software are available to offer advice or assist with configuration if required.
For more information about legacy ciphers refer to: Legacy Ciphers In PaperCut
Keywords: SSL Cipher, CBC, MD5, short bit