SSL Cipher Configuration - removing weak ciphers
Last modified on 12 August 2020 11:21 PM
This article is written for security or network specialists and a certain level of security expertise is assumed.
An often asked question is how to manage SSL cipher lists used by the PaperCut application server. This question may arise in response to comply with policies such as PCI-DSS recommendations, to mitigate potential attacks such as 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.
By default, PaperCut is configured to allow a 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 most secure cipher that the two mutually support. Be aware that reducing the available ciphers may limit support for older browsers or may prevent legacy MFDs from connecting to the PaperCut server, so please take care to test changes thoroughly. Most MFDs will support TLS v1.0 and newer protocols, but older devices may require SSL 3.0, and making some of the changes suggested below will block HTTPS connections from these devices.
Furthermore, the process to configure these settings have been improved in recent versions. Check below to find the instructions specific to your version of PaperCut.
This disables legacy ciphers such as (RC4, 3DES), increases Diffie Hellman key sizes by default and uses stronger elliptic curve families and enables unrestricted crypto policy (eg AES-256) in all TLS communications inbound to the server.
Example setting to configure strict / modern cipher settings:
server.ssl.using-strong-defaults=Y server.ssl.protocols=auto server.ssl.cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
By default, the SSL cipher order preference is set to client cipher order. You can, however, configure the SSL cipher order preference to be server cipher order. Specifying server cipher order allows you to control the priority of ciphers that can be used by the SSL connections from the clients.
SSL Protocols and Cipher Suites can be easily configured by editing the server.properties file found in the application directory. A full list of Cipher Suites and Protocols can be found here: http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html
(Note that in the above example a blacklist of unwanted protocols is used, but a whitelist can be specified if these parameters are used instead: “instead server.ssl.protocols” and “server.ssl.cipher-suites”. However for most situations it is better to use a blacklist instead of a whitelist so that compatibility with newer ciphers and protocols will be ensured without having to modify this file.)
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. For client communication TLS 1.2 is not enabled by default on Java 7 (eg. payment gateway connections from PaperCut to external system). Until version 15.2 which offers Java 8 support and thus TLS 1.2 for client connections active by default this needs to be enabled manually by adding system property
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
Note that currently customizations are not kept across upgrades and any changes will need to be reapplied.
The policy file defines the
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:
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
TIP: After installing the plugin, the list of ciphers supported by your server will be reported in the
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.
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