Is it possible to use .NET Remoting + TLS 1.2 (or

Question

Recently our PCI DSS scan failed, and requires that we disable TLS 1.0 (and enable TLS 1.1 or 1.2). I found the instructions on how to do so on our Windows Server 2008 R2 box, but we have a legacy application that is using .NET Remoting (its a .NET 2.0 windows forms app/IIS hosted CSLA 1.5 data portal), which doesn't communicate with the new settings.

I am getting the following exception:

I have attempted various configurations of combinations of TLS settings in both client and server to no avail. Such as:

1. Disabling TLS 1.0 on both client and server (in the registry) and enabling TLS 1.2.
2. Enabling TLS 1.1 on both client and server (in the registry).

I have done some research and discovered that .NET 4.5 framework supports TLS 1.1 and 1.2, but it is unclear whether that extends to .NET remoting. Does it?

Also, I found that Microsoft's recommendation is to upgrade to 4.5.2.

That said, this application has many dependencies and incompatibilities with .NET 4.5.2, so it would be helpful to know if I am indeed going in the right direction by upgrading or whether I should be in a mad rush to rewrite this application altogether (all options I have explored require major application changes). Even building a test application to try it out could be challenging, since I haven't dealt with .NET remoting directly in about 10 years.

So, again my question is - does .NET remoting support TLS 1.1 or 1.2?

Also:

1. Is upgrading to .NET framework 4.5.2 enough to get it there?
2. Are there more configuration settings that need to be put into place to make it communicate and if so, what are they?
3. If upgrading to .NET framework 4.5.2 is all that is required, does the whole application need to be upgraded, just the parts that use .NET remoting, just the client that references the libraries that use .NET remoting, or some other combination?

I am using:

1. Windows Server 2008 R2 as a server.
2. IIS 7.5 to host the remoting with SSL enababled (CSLA dataportal).
3. Windows 7 Professional for the client.

Answer 1

The following link provided the correct solution for me. I'm using .NET remoting for my portal. My IT department disabled TLS 1.0 on my CSLA servers, and my CSLA libraries were written in .NET 4.0. The fix involves editing the registry on the client machines.

https://success.outsystems.com/Support/Enterprise_Customers/Maintenance_and_Operations/(.NET)_Enable_SSL_Protocols_for_your_Integrations_-_TLS_1.1_and_TLS_1.2

From the Article: To enable the TLS protocols, you need to add new registry entries for the Schannel [1]

For that, please follow this steps:

Start the registry editor by clicking on Start and Run. Type in "regedit" into the Run field (without quotations). Highlight Computer at the top of the registry tree. Backup the registry first by clicking on File and then on Export. Select a file location to save the registry file.

Note: You will be editing the registry. This could have detrimental effects on your computer if done incorrectly, so it is strongly advised to make a backup.

• Browse to the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols Right click on the Protocols folder and select New and then Key from the drop-down menu. This will create new folder. Rename this folder to TLS 1.1 or TLS 1.2 (depending on the protocol you want to enable)
• Right click on the TLS 1.1 or TLS 1.2 key and add a new key underneath it. Rename the new key as: Client
• Right click on the Client key and select New and then DWORD (32-bit) Value from the drop-down list. Rename the DWORD to DisabledByDefault.
• Right-click the name DisabledByDefault and select Modify... from the drop-down menu. Ensure that the Value data field is set to 0 and the Base is Hexadecimal.
• Click on OK.
• Create another DWORD for the Client key as you did in Step 7.
• Rename this second DWORD to Enabled.
• Right-click the name Enabled and select Modify... from the drop-down menu. Ensure that the Value data field is set to 1 and the Base is Hexadecimal.
• Click on OK. Reboot the server After the reboot, the server will be able to communicate through the SSL protocol you enabled. However, you need now to add it to your applications requests.

Enable the SchUseStrongCrypto property in the Windows registry to use as the default protocols: TLS 1.0, TLS 1.1 and TLS 1.2 If you want to make sure strong cryptography is enabled and the SSL protocols for your requests to be TLS 1.0, TLS 1.1 and TLS 1.2, please follow this steps:

Start the registry editor by clicking on Start and Run. Type in "regedit" into the Run field (without quotations).

Highlight Computer at the top of the registry tree. Backup the registry first by clicking on File and then on Export. Select a file location to save the registry file.

Note: You will be editing the registry. This could have detrimental effects on your computer if done incorrectly, so it is strongly advised to make a backup.

• Browse to the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NetFramework\v4.0.30319
• Right-click on the right pane and create a new DWORD (32-bit) Value with Name SchUseStrongCrypto. Ensure that the Value data field is set to 1 and the Base is Hexadecimal. Click on OK.
• Repeat steps 4 and 5 for the registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NetFramework\v4.0.30319
• Reboot the server

Answer 2

This is the error The underlying connection was closed: An unexpected error occurred on a send. I am receiving in my .Net 2.0/.Net 3.5 code when making a http call to code base hosted in IIS Windows 2012 R2.

I have an updated answer to this question. I am also using CSLA(and other http calls to the web server) hosted in Windows 2012 R2 (IIS) and have recently turned off SSL 3.0 and TLS 1.0. There is a handy tool called IISCrypto that will help set your TLS preferences. I have selected "Best Practice" and also unmarked TLS 1.0.

Now to fix the .NET 2.0/3.5 code, there are instructions here. It requires adding SecurityProtocolTypeExtensions.cs and SslProtocolsExtensions.cs to your project and add the code below before making any called to the server side code.

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls | SecurityProtocolTypeExtensions.Tls11 | SecurityProtocolTypeExtensions.Tls12;

I am hoping this will someone work through the error/problems.

Answer 3

I discovered the solution in this obscure MSDN blog post. In order to use TLS 1.2, you have to enable the Group Policy setting for using FIPS complaint encryption algorithms.

That fixes the issue with .NET remoting, click once deployment, and MS Web Deploy. Unfortunately, it broke my ASP.NET web applications and I am still looking for a solution to that issue.