CSLA and TLS 1.2 Issue

[tjoister1]

Due to PCI security concerns, we recently had to drop support for TLS 1.0 and 1.1. That transition went rather smoothly, except for one project that was built in 2005 and uses the CSLA framework. After disabling TLS 1.0 and 1.1 and leaving only TLS 1.2, the application failed.

I upgraded all of the projects in the solution to .NET 4.6.2 hoping that would default to TLS 1.2, and it fixed problems with the ClickOnce deployment and some initial web service calls. However, the first call made by the CSLA framework fails.

The method call is a DataPortal.Fetch and it fails with the following message:

Exception Type: System.Runtime.Serialization.SerializationException Message: End of Stream encountered before parsing was completed. Data: System.Collections.ListDictionaryInternal TargetSite: Void HandleReturnMessage(System.Runtime.Remoting.Messaging.IMessage, System.Runtime.Remoting.Messaging.IMessage)

Additionally, this is more of the call stack:

at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) at CSLA.Server.DataPortal.Fetch(Object Criteria, Object Principal) at CSLA.DataPortal.Fetch(Object Criteria)

This is a very old version of the CSLA framework. I'm not sure what version, because it was built before my time with the company, and there is little to no documentation for this application.

My question is this: Would a new version of the CSLA framework help, or is there something that I can do with the version that I have to make it work with TLS 1.2.

(Side note: It has to be a problem with TLS 1.2, because when we re-enabled TLS 1.0 and 1.1, the application started working again. However, we have a June deadline to permanently disable 1.0 and 1.1).

Thanks for any help you might be able to provide!

[hurcane]

Some general thoughts:

You should be able to find out the version of CSLA by examining the properties of the CSLA.DLL file.

My company also uses an older version of CSLA (3.0 level) and we also had to upgrade some of our projects for TLS 1.2. We did not have any troubles with using CSLA in this configuration. Our CSLA DLL is compiled for .NET 4.0, which is something we had to change in the source, as that version of CSLA originally targeted .NET 2.0. That was done a few years prior to the changes for TLS 1.2.

Versions of CSLA starting with 4.0 and higher are going to have some fundamental breaking changes that you would have to manually resolve. If you have many existing business objects, that could be significant effort. The breaking changes are good changes, but they are not always simple to deal with.

Some thoughts on your specific error:

I would encourage you to track down where your CSLA.dll comes from during your build process. Hopefully, you have the source code. That would allow to debug the problem from the CSLA perspective.

Make sure the server and client are on matching versions of the framework. Different versions can result in strange serialization exceptions.

Another possible cause is that the business object being serialized is holding onto an object that is not serializable. Here's an old forum thread where somebody had a similar error message: http://cslanet.com/old-forum/7745.html

[tjoister1]

Thanks for the quick response!

I was able to track down the CSLA version, which is 1.0.xxxx.xxxxx (the value changes when I rebuild in Visual Studio).

The client and the server are in sync. The server remoting libraries are deployed from the same deployment that creates the ClickOnce distributable that the clients download.

Everything works on TLS 1.1. It is only when we went to TLS 1.2 that we started getting this error. I changed all of the CSLA projects to target .NET 4.6.2, but that didn't help.

And unless the transition is seamless from CLSA v1.0 to v3.x, I'm not sure that's an option, as this project is very old and very, very undocumented.

Thanks again for your help! Any additional thoughts are welcome!

[jonnybee]

Read this article and the comments: https://blogs.perficient.com/microsoft/2016/04/tsl-1-2-and-net-support/

And you should also verify which version of .NET Runtime is installed on the clients.

[tjoister1]

Thanks for the info!

As part of the ClickOnce package, I made .NET 4.6.2 a requirement, and our testing confirms that if it's not present on the client machine, it downloads it prior to installing the application.

In our last round of tests, we created a Fiddler session to hopefully see what was happening, and it fails when invoking the remote DataPortal. The actual HTTP call is successful, it's when the Fetch method is invoked that we get the Serialization error.

[jonnybee]

So where is SSL terminated in relation to you app? Which OS version is your server running on? I would have expected another exception type if it was the TLS config in the framework.

See also: https://support.microsoft.com/en-us/help/3154519/support-for-tls-system-default-versions-included-in-the--net-framework

[tjoister1]

Our web servers are Windows 2012 R2 running IIS 8.5. They sit behind an F5 load balancer, which is where SSL is terminated. Communications between the load balancer and the web servers are done over straight HTTP.

The reason I keep going back to thinking that it is a TLS 1.2 issue is that it worked on all prior versions of SSL/TLS. It was only when we restricted traffic on the load balancer to TLS 1.2 that we started having this issue.

But your question is a good one, and I started going down that troubleshooting path, but I couldn't figure out why it would stop working now, other than the fact that we're restricting communications to use TLS 1.2.

[rockfordlhotka]

Do we know if Microsoft has made Remoting work with TLS 1.2? They haven't recommended using Remoting for network communication for a decade, so perhaps they didn't update it?

[tjoister1]

That's a good question too! There isn't a lot of recent information regarding Remoting, but I can always ask the question on their technical forums. Maybe it's just simply dead in the water...

Thanks for all of your responses!

[rockfordlhotka]

Upgrading from 1.x to 2.x is a relatively big change because that's the point where generics came into play, and CSLA uses those capabilities. From there, getting to 3.5 isn't too bad, and 3.5 is important for you, because that was the point where WCF came into being and CSLA was refactored to decouple from Remoting.

So at 3.5 is where it is easy to switch from Remoting to asmx or WCF as a network transport (or create your own).

From 3.5-4.0 there were a bunch of intermediate changes, including a rules engine that didn't survive into 4.0. So I'd skip 3.6 and 3.8 and go right to 4.x if you want to make that change.

The thing is, 3.5 is probably your sweet spot (if there is one) because it predates all the really cool-but-disruptive stuff that is now in CSLA - like the modern rules engine, compact properties, more powerful data portal options, cross-platform, etc.

Getting from 1.x to 3.5 won't be easy, but getting to 4.x would be a much bigger task.

[tjoister1]

Thanks again! We're weighing our options, but it's starting to look like we've hit the wall as far as the Remoting technology goes.

[hurcane]

I think I misunderstood your situation, and I might now understand how your situation differs from ours. It sounds like you are wanting to use TLS 1.2 with the data portal calls.

Our data portal is typically implemented via component services. We use TLS 1.2 within business objects for communication with external parties, such as submitting orders via a vendor's web API, but we are not using it "in house".

As usual, Rocky has succinctly described your best options.