Disable Cipher

replied on December 24, 2024

I would recommend using IIS Crypto if you aren't already (https://youtu.be/158to6ZgMro). When an application initiates an SSL handshake with another server it lets it know what Cipher Suites it supports and looks at its own list to see if any of them match. The order of the cipher suites is important because that is how it compares the lists. As long as it is able to find a supported cipher suite on both sides it makes the connection. If it doesn't then your application won't complete the SSL handshake.

You can see that this is more of an OS type of configuration. If I recall, if you are on the latest versions of Laserfiche 11 or 12 then the Laserfiche applications will use the cipher suites configured by the OS. If you are using older versions of Laserfiche 11 or earlier, some manual configuration may be needed in order for them to work correctly.

I hope that helped.

2 0

replied on January 2

If I recall, if you are on the latest versions of Laserfiche 11 or 12 then the Laserfiche applications will use the cipher suites configured by the OS.

I believe this has been true since we first supported https - we have always used the Windows-supplied implementation, called "schannel". This means that encryption is configured and handled entirely at the OS level, and is transparent to our applications. So you're right that it's going to be more about Windows policies and configuration than about application configuration. Any problems or incompatibilities should surface on any test machine and our applications won't require significant additional testing.

Do recall that applications like Chrome, Firefox, and Internet Explorer are part of your solution, and I believe some of these have their own TLS implementations separate from the OS. So for thoroughness you should test to make sure these are still able to connect to the updated servers. There really isn't a risk here if all you are doing is dropping obsolete ciphers and you are on recent versions of the browsers.

The other exception to be aware of is the mobile app, which will use the iOS or Android TLS implementation, and so may need to be managed separately. But again, as long as your devices are updated regularly and you are just dropping obsolete ciphers, there isn't a practical concern here.

The list of ciphers they want to drop are ones that do not support "Perfect Forward Secrecy". There is a whole newer generation of ciphers like TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 that do support PFS. These are all widely supported and this is a common migration path, so you should expect this to go smoothly.

1 0

replied on January 2 • Show version history

Re:

Is there a way to verify what Laserfiche uses or if anything would break by disabling these? Their current system has been up and working for some time now so this would be a change to the current environment and not anything on a new system.

If they are looking to allow only TLS 1.2 cipher with Perfect Forward Secrecy, they likely have already disabled TLS 1.0 and 1.1. Verify this for both Client and Server protocol lists on all application and database servers.

If the current Laserfiche system is working with TLS 1.0 and 1.1 disabled, so you can be sure it's using TLS 1.2 exclusively, you should have nothing to worry about from telling Windows (schannel) to only use a subset of TLS 1.2 ciphers. Laserfiche applications don't have visibility into which cipher suites are enabled or used in the first place.

If TLS 1.0 and/or 1.1 are still enabled on the servers at any level, and especially if any Laserfiche software component was last updated over 2 years ago, we recommend first setting some Windows/.NET "Use TLS 1.2" compatibility settings on all the servers first. Setting the two "SchUseStrongCrypto" registry keys to "1" tells older 32/64-bit .NET Framework applications to use the operating system default TLS version (TLS 1.2 for Windows Server 2016+). Without it, they may try to use TLS 1.0. The setting will not affect newer .NET Framework (4.7.1+) applications, which automatically use the OS default TLS version.

You can set the registry values that by running the following PowerShell commands. A Windows reboot is required for the settings update to take effect.

# PowerShell

# Enable TLS 1.2 for .NET Framework 4.5-4.7.0 - x64/x86
# Prior to .NET Framework 4.7.1, .NET WCF did not use the system default TLS settings
# Ref: https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls
# Ref: https://learn.microsoft.com/en-us/mem/configmgr/core/plan-design/security/enable-tls-1-2-client#configure-for-strong-cryptography

New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -value '1' -Type 'DWord' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type 'DWord' -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type 'DWord' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type 'DWord' -Force | Out-Null

Write-Host -ForegroundColor Red 'A computer restart is required to apply settings.'

1 0

Question

Question

Replies

Sign in to reply to this post.