SSL Cipher Configuration - removing weak ciphers

KB Home   |   SSL Cipher Configuration - removing weak ciphers

Main.SSLCipherConfiguration History

Hide minor edits - Show changes to output

November 22, 2018, at 03:48 AM by 139.130.165.134 -
Added lines 10-17:

!! [-Configure best  practice cipher and removing weak ciphers easily - Version 18.2 and above-]
# In a text editor, open the following file: [@
[app-path]/server/server.properties @]
# Locate the line starting with "server.ssl.using-strong-defaults"
# Remove the proceeding # sign to uncomment the lines and edit the list as needed.
# Set the value after = sign to 'Y' so it looks like: [@server.ssl.using-strong-defaults=Y@] and restart the server.
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.
March 08, 2018, at 02:37 AM by amir - java 7 client SSL protocol clarification
Changed lines 39-43 from:
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.
to:
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
[@-Dhttps.protocols=TLSv1.1,TLSv1.2 @]
See service.conf on Windows and launch scripts on Linux/Mac.

August 16, 2017, at 06:09 AM by 139.130.165.134 -
Changed lines 16-17 from:
# Locate the line starting with "cipher preference: client"
# Change client
to server (cipher preference: server).
to:
# Locate the line starting with "server.ssl.follow-client-cipher-order"
# Remove the proceeding # sign
to uncomment the lines and edit the list as needed.
# Change client to server.ssl.follow-client-cipher-order=N
(cipher preference: server).
June 21, 2017, at 08:46 PM by Aaron Pouliot - Fixed version number from 17.0 to 16.2
Changed line 11 from:
!! [-Configure the SSL cipher order preference (version 17.1 and above)-]
to:
!! [-Configure the SSL cipher order preference- Version 17.1 and above-]
Changed line 21 from:
!! [-Disable specific ciphers and protocols (version 17.0 and above)-]
to:
!! [-Disable specific ciphers and protocols- Version 16.2 (Build 37799) and above-]
June 01, 2017, at 11:39 PM by Aaron Pouliot - standardized formatting, condensed introduction, added information about cipher whitelists
Changed lines 5-11 from:
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 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 manage SSL cipher lists used 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 [[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3389|CVE-2011-3389]]) or in order to implement a security policy such as support for Perfect Forward Secrecy in TLS communications.

The process to configure these settings have been improved in recent versions. Check below to find the instructions specific to your version of PaperCut. '''When making any changed be absolutely certain to follow best practices while testing as certain settings may prevent older clients from printing or legacy MFPs from connecting to the PaperCut server.'''
to:
An oft 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 [[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3389|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.
Changed line 16 from:
# Locate the line starting with cipher preference: client 
to:
# Locate the line starting with "cipher preference: client"
Changed lines 21-22 from:
!! [-Version 17 and above-]
SSL Protocols
and Cipher Suites can be easily configured by editing the [@server.properties@] file found in the application directory. Uncomment the two lines at the bottom of the section ''SSL Protocols/Ciphers'' starting with [@#lines server.ssl.disabled-protocols@] and [@#server.ssl.disabled-cipher-suites@] by removing the proceeding # signs.  See example below:
to:
!! [-Disable specific ciphers and protocols (version 17.0 and above)-]
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]]
Changed lines 24-28 from:
[@
### SSL Protocols/Ciphers ###
# All allowed SSL protocols and cipher suites
# Refer to http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html
# Eg. To use only TLS protocols and drop RC4 enabled by default, use the following
:
to:
# In a text editor, open the following file: [@
[app-path]/server/server.properties @]
# Locate the two lines starting with "#server.ssl.disabled-protocols"  and  "#server.ssl.disabled-cipher-suites"
# Remove the proceeding # sign to uncomment the lines and edit the list as needed.
# To only allow TLS protocols and disable support for RC4, use the sample lines below
: [@
Changed lines 30-36 from:
server.ssl.disabled-cipher-suites=SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA
@]

After modifying and saving this file restart the application server for the changes to apply.

Take care and test thoroughly if you are running a fleet of MFD devices with PaperCut MF.  Whilst some MFDís do not support all TLS versions, most will support TLS v1.0.  It is possible that some older MFDís may require SSL 3.0 and the above configuration change will block HTTPS connections from these devices.
to:
server.ssl.disabled-cipher-suites=SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA @]
# Save the file.
# Restart
the PaperCut Application Server service.

(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.)
Changed line 64 from:
!! [-Earlier versions-]
to:
!! [-Older Versions-]
May 10, 2017, at 06:10 AM by 139.130.165.134 - added 17.1 info
Added lines 11-20:

!! [-Configure the SSL cipher order preference (version 17.1 and above)-]
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.

# In a text editor, open the following file: [@
[app-path]/server/server.properties @]
# Locate the line starting with cipher preference: client
# Change client to server (cipher preference: server).
# Save the file.
# Restart the PaperCut Application Server service.
May 04, 2017, at 12:05 AM by Aaron Pouliot -
Added lines 23-26:

After modifying and saving this file restart the application server for the changes to apply.

Take care and test thoroughly if you are running a fleet of MFD devices with PaperCut MF.  Whilst some MFDís do not support all TLS versions, most will support TLS v1.0.  It is possible that some older MFDís may require SSL 3.0 and the above configuration change will block HTTPS connections from these devices.
May 03, 2017, at 11:55 PM by Aaron Pouliot - Reorganized article to sort instructions under version-specific sections
Changed lines 5-7 from:
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.
to:
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 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 manage SSL cipher lists used by the PaperCut application server.
Changed lines 10-13 from:
The configuration process is different depending on PaperCut version thatís in use, but in recent versions of PaperCut this can be configured by editing the "server.properties" file found in the application directory. Uncomment the two lines at the bottom of the section ''SSL Protocols/Ciphers'' starting with "lines server.ssl.disabled-protocols" and "server.ssl.disabled-cipher-suites" by removing the proceeding # signBe absolutely certain to follow best practices while testing these changes as it could prevent clients from printing or certain legacy MFPs from connecting to the PaperCut server. See example below:
to:
The process to configure these settings have been improved in recent versions. Check below to find the instructions specific to your version of PaperCut. '''When making any changed be absolutely certain to follow best practices while testing as certain settings may prevent older clients from printing or legacy MFPs from connecting to the PaperCut server.'''

!! [-Version 17 and above-]
SSL Protocols and Cipher Suites can be easily configured by editing the [@server.properties@] file found in the application directory. Uncomment the two lines at
the bottom of the section ''SSL Protocols/Ciphers'' starting with [@#lines server.ssl.disabled-protocols@] and [@#server.ssl.disabled-cipher-suites@] by removing the proceeding # signs. See example below:
Deleted lines 23-41:

!!! [-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.

Changed lines 72-73 from:

This is a complex topic and the security-focused team at PaperCut Software are available to offer advice or assist with configuration if required.
to:
!! [-Other Considerations-]

!!! [-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.
May 03, 2017, at 10:35 PM by Aaron Pouliot -
Changed line 10 from:
The configuration process is different depending on PaperCut version thatís in use, but in recent versions of PaperCut this can be configured by editing the "server.properties" file found in the application directory. Uncomment the two lines at the bottom, starting with "lines server.ssl.disabled-protocols" and "server.ssl.disabled-cipher-suites" by removing the proceeding # sign.  Be absolutely certain to follow best practices while testing these changes as it could prevent clients from printing or certain legacy MFPs from connecting to the PaperCut server. See example below:
to:
The configuration process is different depending on PaperCut version thatís in use, but in recent versions of PaperCut this can be configured by editing the "server.properties" file found in the application directory. Uncomment the two lines at the bottom of the section ''SSL Protocols/Ciphers'' starting with "lines server.ssl.disabled-protocols" and "server.ssl.disabled-cipher-suites" by removing the proceeding # sign.  Be absolutely certain to follow best practices while testing these changes as it could prevent clients from printing or certain legacy MFPs from connecting to the PaperCut server. See example below:
May 03, 2017, at 10:31 PM by Aaron Pouliot -
Changed line 10 from:
The configuration process is different depending on PaperCut version thatís in use, but in recent versions of PaperCut this can be configured by editing the "server.properties" file found in the application directory. Uncomment the two lines at the bottom, starting with "lines server.ssl.disabled-protocols" and "server.ssl.disabled-cipher-suites" by removing the proceeding # sign.  Be absolutely certain to follow best practices while testing these changes as it could prevent clients from printing or certain legacy MFPs from connecting to the PaperCut server.
to:
The configuration process is different depending on PaperCut version thatís in use, but in recent versions of PaperCut this can be configured by editing the "server.properties" file found in the application directory. Uncomment the two lines at the bottom, starting with "lines server.ssl.disabled-protocols" and "server.ssl.disabled-cipher-suites" by removing the proceeding # sign.  Be absolutely certain to follow best practices while testing these changes as it could prevent clients from printing or certain legacy MFPs from connecting to the PaperCut server. See example below:
May 03, 2017, at 10:29 PM by Aaron Pouliot - Added information about configuring SSL Protocols and Cipers in server.properties
Changed lines 10-11 from:
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.
to:
The configuration process is different depending on PaperCut version thatís in use, but in recent versions of PaperCut this can be configured by editing the "server.properties" file found in the application directory. Uncomment the two lines at the bottom, starting with "lines server.ssl.disabled-protocols" and "server.ssl.disabled-cipher-suites" by removing the proceeding # sign.  Be absolutely certain to follow best practices while testing these changes as it could prevent clients from printing or certain legacy MFPs from connecting to the PaperCut server.
 
[@
### SSL Protocols/Ciphers ###
# All allowed SSL protocols and cipher suites
# Refer to http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html
# Eg. To use only TLS protocols and drop RC4 enabled by default, use the following:
server.ssl.disabled-protocols=SSLv2Hello, SSLv3
server.ssl.disabled-cipher-suites=SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA
@]

September 26, 2016, at 03:25 AM by amir - legacy ciphers link
Added lines 81-82:

For more information about legacy ciphers refer to: [[LegacyCiphersInPaperCut|Legacy Ciphers In PaperCut]]
July 11, 2016, at 11:51 PM by matt - Move the version info stuff to the bottom.
Added lines 13-30:
!!! [-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.

Deleted lines 57-74:

!!! [-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.
April 28, 2015, at 04:04 AM by amir - Update article
Changed lines 18-19 from:
PaperCut places its Java Runtime under [@[app-path]/runtime@] folder with minor variation due to system specifics, eg: [@[app-path]/runtime/win64@] on 64 bit Windows for example.
to:
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
.
Changed line 27 from:
By default, as of Java 7 the following policy applies:
to:
As an example the following more secure policy default can be applied:
Changed lines 48-49 from:
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 (1024 bits).
to:
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).
Changed line 17 from:
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 [@<JRE>/lib/security@] directory.
to:
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 [@[app-path]/[JRE]/lib/security@] directory.
April 27, 2015, at 01:09 AM by Jason - We use [app-path] everywhere else.
Changed lines 18-19 from:
PaperCut places its Java Runtime under [@<PaperCutHome>/runtime@] folder with minor variation due to system specifics, eg: [@<PaperCutHome>/runtime/win64@] on 64 bit Windows for example.
to:
PaperCut places its Java Runtime under [@[app-path]/runtime@] folder with minor variation due to system specifics, eg: [@[app-path]/runtime/win64@] on 64 bit Windows for example.
April 22, 2014, at 10:00 PM by 203.12.22.94 -
Changed lines 18-19 from:
PaperCut places its Java Runtime under [@<PaperCutHome>/runtime@] folder with minor variation due to system specifics, eg: [@<PaperCutHome>/runtime/win64@] on 64 bit windows for example.
to:
PaperCut places its Java Runtime under [@<PaperCutHome>/runtime@] folder with minor variation due to system specifics, eg: [@<PaperCutHome>/runtime/win64@] on 64 bit Windows for example.
April 22, 2014, at 09:59 PM by 203.12.22.94 -
Changed line 10 from:
In future versions of PaperCut we may make the decision to remove some of the default ciphers. The merits and impact of this change are still being discussed internally.
to:
In future versions of PaperCut we may make the decision to remove some of the default ciphers.
Changed lines 18-19 from:
PaperCut places its Java Runtime under [@<PaperCutHome>/runtime@] folder. (Look in the win64 folder if using a 64-bit system for example.)
to:
PaperCut places its Java Runtime under [@<PaperCutHome>/runtime@] folder with minor variation due to system specifics, eg: [@<PaperCutHome>/runtime/win64@] on 64 bit windows for example.
Changed lines 33-36 from:
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 [[http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx|SHA-2 in MS Windows]]).

One can find all the cipher suites enabled by default in Java 7 here: [[http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html|Default Cipher Suites in Java 7]] (if the default [=SunJSSE=] provider is used).
to:
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 [[http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx|Windows XP SP3]]).

One can find all the cipher suites enabled by default in Java 7 here: [[http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html|Default Cipher Suites in Java 7]] (unless the default [=SunJSSE=] crypto provider has been explicitly overridden and is not used).
Changed lines 39-40 from:
Finally one other security concept 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.
to:
!!! [-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.
Changed lines 44-49 from:
In order to accomplish this one would cull down 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 (1024 bits), in fact this won't fully be possible until Java 8 which has only just been released, for further details please to this [[https://bugs.openjdk.java.net/browse/JDK-6956398|Open JDK Bug Report]].

Whilst it is not possible to define a preferred cipher order
on the server side (again until Java 8) the chosen cipher will be selected from the cut down list, but which one will depend on the client connecting to the server.
to:
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 (1024 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.
Changed lines 53-56 from:
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. In general the cryptographic technology on these devices vary and sometimes lag behind current best practice. In some extreme cases this means that we simply cannot 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 one can 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.
to:
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.
April 22, 2014, at 04:10 AM by 203.12.22.94 -
Changed lines 47-48 from:
Whilst it is not possible is to define a preferred cipher order on the server side (again until Java 8) so the chosen cipher will be selected from the cut down list, but which one will depend on the client connecting to the server.
to:
Whilst it is not possible to define a preferred cipher order on the server side (again until Java 8) the chosen cipher will be selected from the cut down list, but which one will depend on the client connecting to the server.
Changed line 17 from:
Java 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 [@<JRE>/lib/security@] directory.
to:
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 [@<JRE>/lib/security@] directory.
Changed lines 33-34 from:
To imporive 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 [[http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx|SHA-2 in MS Windows]]).
to:
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 [[http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx|SHA-2 in MS Windows]]).
April 22, 2014, at 04:01 AM by Alec - Tarted up the English
Changed lines 3-4 from:
This KB article is intended for a security or network specialist.
to:
This article is written for security or network specialists and a certain level of security expertise is assumed.
Changed lines 15-16 from:
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 and which only targets inbound communications. Java 7 also offers TLS 1.2 support.
to:
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.
Changed lines 20-22 from:
The policy file defines [@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 Oracle site:
to:
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:
Changed lines 28-30 from:
Which boils down to requesting: no MD5, no SHA1, no DSA. RSA is allowed only if the key is at least 2048 bits long.

This setting can be customized to further tailor a given deployment to oneís needs.
to:
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.
Changed lines 33-34 from:
To further turn the dial towards a more secure set of cipher suites one can disallow ''SHA1'' and ''RC4'' this may come at the cost of breaking compatibility with some Windows XP based software (eg Windows XP itself didnít include ''SHA2'' support initially [[http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx|SHA-2 in MS Windows]]).
to:
To imporive 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 [[http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx|SHA-2 in MS Windows]]).
Changed lines 37-38 from:
Another noteworthy point is that if ''AES-256'' encryption is selected then this will also require obtaining "Unlimited Strength Jurisdiction Policy files" from the [[http://www.oracle.com/technetwork/java/javase/downloads/index.html|Oracle Java Download Page]]
to:
Please note that if ''AES-256'' encryption is selected then this will also require obtaining "Unlimited Strength Jurisdiction Policy files" from the [[http://www.oracle.com/technetwork/java/javase/downloads/index.html|Oracle Java Download Page]]
Changed lines 45-50 from:
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 (1024 bits), in fact this won't fully be possible until Java 8 which has only just been released: [[https://bugs.openjdk.java.net/browse/JDK-6956398|Open JDK Bug Report]].

What is also not possible is to define a preferred cipher order on the server side (again until Java 8) so the chosen cipher will be selected from the cut down list but which one will depend on the client connecting to the server.

In summary PFS operation mode can be achieved but with varying degree of strength and tinkering required. The number of potentially compatible clients will also decrease as the cipher suites are culled.
to:
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 (1024 bits), in fact this won't fully be possible until Java 8 which has only just been released, for further details please to this [[https://bugs.openjdk.java.net/browse/JDK-6956398|Open JDK Bug Report]].

Whilst it is not possible is to define a preferred cipher order on the server side (again until Java 8) so the chosen cipher will be selected from the cut down list, but which one will depend on the client connecting to the server.

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.
Changed lines 52-55 from:
This however is not the end of the story. With PaperCut MF we have to interface with various copiers and devices created by third parties, in general the 'crypto' technology stacks on these devices vary and sometimes lag behind. In some extreme cases this means that we simply cannot 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 this as a
guidance on how one can 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.
to:
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. In general the cryptographic technology on these devices vary and sometimes lag behind current best practice. In some extreme cases this means that we simply cannot 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 one can 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.
Changed lines 57-58 from:
We have developed a plugin that will allow configuration of the cipher list in both current and older versions of PaperCut (version 11 through 13). The plugin configures connections at the Jetty (embedded HTTP server and servlet engine).
to:
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).
April 22, 2014, at 12:30 AM by 203.12.22.94 -
Added line 51:
!!! [-SSL/TLS and MFDs-]
April 22, 2014, at 12:19 AM by 203.12.22.94 -
Changed lines 3-4 from:
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.  One motivation for removing ciphers would be to mitigate a potential attack via the BEAST SSL vulnerability ([[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3389|CVE-2011-3389]]) or implement support for Perfect Forward Secrecy in TLS communications.
to:
This KB article is intended for a security or network specialist.

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 [[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3389|CVE-2011-3389]]) or in order to implement a security policy such as
support for Perfect Forward Secrecy in TLS communications.
Changed lines 45-46 from:
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 (1024 bits), in fact this won't fully be possible until Java 8: [[https://bugs.openjdk.java.net/browse/JDK-6956398|Open JDK Bug Report]] (which has only just been released).
to:
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 (1024 bits), in fact this won't fully be possible until Java 8 which has only just been released: [[https://bugs.openjdk.java.net/browse/JDK-6956398|Open JDK Bug Report]].
April 22, 2014, at 12:14 AM by 203.12.22.94 -
Changed lines 3-4 from:
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 browser 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.  One motivation for removing ciphers would be to mitigate a potential attack via the BEAST SSL vulnerability ([[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3389|CVE-2011-3389]]) or implement support for Perfect Forward Secrecy in TLS communications.
to:
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.  One motivation for removing ciphers would be to mitigate a potential attack via the BEAST SSL vulnerability ([[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3389|CVE-2011-3389]]) or implement support for Perfect Forward Secrecy in TLS communications.
April 17, 2014, at 06:43 AM by 203.12.22.94 -
Changed lines 15-16 from:
The policy file defines ''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.
to:
The policy file defines [@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.
April 17, 2014, at 06:29 AM by 203.12.22.94 -
Changed lines 10-11 from:
This offers improved flexibility when trying to accomplish the goals of precise control over the user of ciphers and applies globally to the JVM without needing to configure the Jetty web server and which only targets inbound communications. Java 7 also offers TLS 1.2 support.
to:
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 and which only targets inbound communications. Java 7 also offers TLS 1.2 support.
April 17, 2014, at 06:28 AM by 203.12.22.94 -
Changed lines 3-6 from:
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 browser 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.  One motivation for removing ciphers would be to mitigate a potential attack via the BEAST SSL vulnerability ([[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3389|CVE-2011-3389]]).

In future versions of PaperCut we may make the decision to remove some of the default ciphers.  The merits and impact of this change are still being discussed internally.  In the meantime we have developed a plugin that will allow configuration of the cipher list in ''both'' current and older versions of PaperCut (version 11 through 13).

to:
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 browser 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.  One motivation for removing ciphers would be to mitigate a potential attack via the BEAST SSL vulnerability ([[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3389|CVE-2011-3389]]) or implement 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 merits and impact of this change are still being discussed internally.
The configuration process is different depending on PaperCut version thatís 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 user of ciphers and applies globally to the JVM without needing to configure the Jetty web server and which only targets inbound communications. Java 7 also offers TLS 1.2 support.

Java 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 [@<JRE>/lib/security@] directory.
PaperCut places its Java Runtime under [@<PaperCutHome>/runtime@] folder. (Look in the win64 folder if using a 64-bit system for example.)

The policy file defines ''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 Oracle site:
[[http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#DisabledAlgorithms|JSSE Reference Guide]]

By default, as of Java 7 the following policy applies:
[@jdk.tls.disabledAlgorithms=MD5, SHA1, DSA, RSA keySize < 2048@]

Which boils down to requesting: no MD5, no SHA1, no DSA. RSA is allowed only if the key is at least 2048 bits long.

This setting can be customized to further tailor a given deployment to oneís needs.
For example as a starting point ďexportĒ strength ciphers as well as ''DES''/''3DES'' and ''MD5'' based cipher suites can be removed.

To further turn the dial towards a more secure set of cipher suites one can disallow ''SHA1'' and ''RC4'' this may come at the cost of breaking compatibility with some Windows XP based software (eg Windows XP itself didnít include ''SHA2'' support initially [[http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx|SHA-2 in MS Windows]]).

One can find all the cipher suites enabled by default in Java 7 here: [[http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html|Default Cipher Suites in Java 7]] (if the default [=SunJSSE=] provider is used).

Another noteworthy point is that if ''AES-256'' encryption is selected then this will also require obtaining "Unlimited Strength Jurisdiction Policy files" from the [[http://www.oracle.com/technetwork/java/javase/downloads/index.html|Oracle Java Download Page]]

Finally one other security concept 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 one would cull down 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 (1024 bits), in fact this won't fully be possible until Java 8: [[https://bugs.openjdk.java.net/browse/JDK-6956398|Open JDK Bug Report]] (which has only just been released).

What is also not possible is to define a preferred cipher order on the server side (again until Java 8) so the chosen cipher will be selected from the cut down list but which one will depend on the client connecting to the server.

In summary PFS operation mode can be achieved but with varying degree of strength and tinkering required. The number of potentially compatible clients will also decrease as the cipher suites are culled.

This however is not the end of the story. With PaperCut MF we have to interface with various copiers and devices created by third parties, in general the 'crypto' technology stacks on these devices vary and sometimes lag behind. In some extreme cases this means that we simply cannot 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 this as a guidance on how one can 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.

!! [-Earlier versions-]
We have developed a plugin that will allow configuration of the cipher list in both current and older versions of PaperCut (version 11 through 13). The plugin configures connections at the Jetty (embedded HTTP server and servlet engine).

January 29, 2013, at 11:04 AM by 203.206.99.153 -
Changed line 30 from:
[-Keywords: SSL Cipher -]
to:
[-Keywords: SSL Cipher, CBC, MD5, short bit -]
January 29, 2013, at 10:34 AM by 203.206.99.153 -
Changed lines 20-21 from:
# Restart the PaperCut Application Server and re-test with an appropriate security scanning tool.
to:
# Restart the ''PaperCut Application Server'' service and re-test with an appropriate security scanning tool.
January 29, 2013, at 10:33 AM by 203.206.99.153 -
Changed lines 9-10 from:
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: [[(Attach:)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:
to:
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: [[(Attach:)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:
January 29, 2013, at 10:33 AM by 203.206.99.153 -
Changed lines 9-10 from:
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: [[(Attach:)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:
to:
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: [[(Attach:)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:
January 29, 2013, at 10:32 AM by 203.206.99.153 -
Changed lines 5-8 from:
In future versions of PaperCut we may make the decision to remove some of the default ciphers.  The merits and impact of this change are still being discussed internally.  In the meantime we have developed a plugin that will allow configuration of the cipher list in current and older versions (version 11 through 13).

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 a production system. The plugin can be applied to any edition of PaperCut with minimal impact and downtime.
to:
In future versions of PaperCut we may make the decision to remove some of the default ciphers.  The merits and impact of this change are still being discussed internally.  In the meantime we have developed a plugin that will allow configuration of the cipher list in ''both'' current and older versions of PaperCut (version 11 through 13).

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.
Changed lines 9-11 from:
It is intended that an experienced system administrator install and configure this plugin, with careful testing required after implementation.  Download the plugin TODO here TODO.  Unzip the contents; installation and configuration steps are outlined in the [@README-JETTY-CONFIG.txt@].  In summary, the process will involve:

# Unzip
[@jetty-config-plugin.zip@]
to:
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: [[(Attach:)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:

# Unzip [@jetty-config-plugin-v1
.zip@]
Added lines 23-24:
This is a complex topic and the security-focused team at PaperCut Software are available to offer advice or assist with configuration if required.
Changed line 26 from:
''Categories:'' [[Category.TODOFirstCategory|+]], [[Category.TODOSecondCategoryIfNeeded|+]]
to:
''Categories:'' [[Category.Security|+]]
Changed lines 3-4 from:
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 browser 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.  One motivation for removing ciphers would be to mitigate a potential attack via the BEAST SSL vulnerability (CVE-2011-3389).
to:
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 browser 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.  One motivation for removing ciphers would be to mitigate a potential attack via the BEAST SSL vulnerability ([[http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3389|CVE-2011-3389]]).
Changed lines 9-11 from:
It is intended that an experienced system administrator install and configure this plugin, with careful testing required after implementation.

to:
It is intended that an experienced system administrator install and configure this plugin, with careful testing required after implementation.  Download the plugin TODO here TODO.  Unzip the contents; installation and configuration steps are outlined in the [@README-JETTY-CONFIG.txt@].  In summary, the process will involve:

# Unzip [@jetty-config-plugin.zip@]
# Review [@README-JETTY-CONFIG.txt@]
# Copy the following files to [@[app-path]\server\lib-ext@]
## [@jetty-config.plugin@]
## [@jetty-config-plugin.jar@]
## [@jetty-config-plugin.properties@]
# 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 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
.

Added lines 1-15:
(:title SSL Cipher Configuration - removing weak ciphers :)

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 browser 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.  One motivation for removing ciphers would be to mitigate a potential attack via the BEAST SSL vulnerability (CVE-2011-3389).

In future versions of PaperCut we may make the decision to remove some of the default ciphers.  The merits and impact of this change are still being discussed internally.  In the meantime we have developed a plugin that will allow configuration of the cipher list in current and older versions (version 11 through 13).

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 a production system. The plugin can be applied to any edition of PaperCut with minimal impact and downtime.

It is intended that an experienced system administrator install and configure this plugin, with careful testing required after implementation.


----
''Categories:'' [[Category.TODOFirstCategory|+]], [[Category.TODOSecondCategoryIfNeeded|+]]
----
[-Keywords: SSL Cipher -]

Comments

Share your findings and experience with other PaperCut users. Feel free to add comments and suggestions about this Knowledge Base article. Please don't use this for support requests.

Article last modified on November 22, 2018, at 03:48 AM
Printable View   |   Article History   |   Edit Article