DOT NET + TLS BEHAVIOR SECRETS

This article includes critical & important relationship dependencies on how exactly DOT NET (.NET) compiled applications function with and along side TLS.  For non-developers, you most certainly will find this article extremely helpful in how we disentangle multiple hidden secrets and dependencies between DOT NET Apps + TLS.

With the number of release-versions of .NET Framework, there are MANY important aspects concerning TLS behavior which should be closely observed and certainly understood.  For instance, let’s consider 4.62 compiled apps natively negotiate TLS differently latter versions. Wow!

At the time of this post Microsoft happens to support a wide range of ten (10) versions of DOT NET (.NET) Framework Runtime for their two (2) versions of Common Language Runtime (CLR) – click for list.

FUNDAMENTALS

Securing or remediating TLS simply means ensuring the business is functioning at and utilizing the most secure instance or version.  At present, TLS 1.2 is the recommended (secure) version.

When working with, securing or remediating enterprise TLS, there are three (3) distinctly separate components one needs to be intimately familiar with:

• • Compiled Applications
  • DOT NET (.NET) Framework
  • SCHANNEL

• A Windows computer can support multiple Common Language Runtime (CLR). For example, Runtime 2.0 (Dot Net 3.0) or Runtime 4.0 (DOT NET 4.0)
• The current (installed) revision of DOT NET (.NET) Framework Runtime is capable of executing compiled application at that version. For example, DOT NET FW 4.7 runtime is capable of executing 4.7 compiled apps.
• The version .NET Framework Runtime maintains backward compatibility, capable of executing previous (or older) .NET applications previous to its own. This is restricted to it’s own Common Language Runtime (CLR). For example, DOT NET FW 4.8 runtime is capable executing all previous compiled apps (4.7, 4.62, 4.52, etc.) or 3.51 runtime is capable executing all previous compiled apps (3.5,etc.)

More importantly, Every DOT NET (.NET) compiled client-application maintains its own built-in, unique & defined set of TLS protocol instructions and behavior(s).

Nearly all DOT NET (.NET) compiled apps have varying TLS negotiation behavior (see diagram example below). This can be a bit frustrating.  On Windows computers, in order to accommodate for the numerous and varying application versions, admins routinely install a current versions of the DOT NET (.NET) Framework Runtime. Newer versions of Windows also come with the near current versions of the Runtime Framework.  In addition, the Framework is routinely updated (or maintained).  In other words, regularly patched.

Maintaining current versions of DOT NET (.NET) Framework Runtime, on client computers, in addition provides backward (execution) compatibilities for previous DOT NET (.NET) compiled application-versions. (see support Runtime versions). Above all, we want to keep our client working.  Clear as mud?

In other words, DOT NET (.NET) Framework Runtime version 4.7 is required for:

1. 1. Existing 4.7 compiled applications
   2. Previously compiled application versions (4.62, 4.6, 4.52, etc.)

In the case above, if running a 4.8 application, one would need to install the latest 4.8 Framework Runtime.

These DOT NET (.NET) apps have built-in and default TLS behavior(s) – for instance, how the application interacts and negotiates using SCHANNEL. You’re not alone – as a result, this can be a bit confusing.

DOT NET (.NET) applications compiled prior to 4.7 maintain built-in and defined TLS negotiation instructions. In other words, these DOT NET (.NET) apps instruct SCHANNEL which TLS protocols (in sequence) to negotiate.

Take for example:

• • 4.5.2 DOT NET (.NET) 4.5.2 applications instruct SCHANNEL to negotiate TLS protocol in the following order:
    • 1.) TLS 1.0 then
    • 2.) SSL 3.0.
  • 4.6.2 DOT NET (.NET) applications instruct SCHANNEL to negotiate in this order:
    1. TLS 1.2 then
    2. TLS 1.1 then
    3. TLS 1.0.
  • 4.7 DOT NET (.NET) and newer applications (by default) rely on the operating system to negotiate TLS.

(note: although there should not be any reason, the 4.7 default behavior can be disabled.  If disabled, 4.7+ compiled apps would assume the built-in behavior for 4.6 & 4.6.2.)

Newer iterations of .NET, Microsoft has gradually introduced new safeguards which simplifies and standardizes this negotiation process.

Similarly, applications compiled prior to 4.7 versions have built in and defined protocols. As a result, these protocols are passed to, and instruct SCHANNEL which protocols to negotiate.

Above all, as .NET Framework advances, TLS protocol behavior has become more uniform and predictable.

Let’s take another example; the default behavior for 4.7 compiled applications relies exclusively on SCHANNEL to control and negotiate the highest possible (available) version of TLS. If for instance, TLS 1.1 & 1.2 are the only SCHANNELs client protocols enabled, the operating system will negotiate TLS 1.2.

In conclusion, I hope this provides a bit more light on the relationship and dependencies between DOT NET (.NET) Framework, applications and SCHANNEL TLS.

Warmest Regards,

SHAWN MAY – DTS Inc. | Principal Architect & CEO | shawn@yourDTS.com

CORE PRACTICES

• Implementing correct solutions
• Bringing the correct talent (professional-staff-augmentation or project team)
• Alignment to the business functional & functional direction
• Maintaining agility with communication and options
• Ensure to have a properly scoped project and accurate roadmap eliminating fluff

Stay Well

Here are some incredibly-simple videos to watch & share with co-workers, family and friend on staying well:

• How to Keep Yourself & Others Well
• About Bacteria & Virus
• What to Do If You’re Ill
• Why Prevention Is Important
• Solutions for a Dangerous Environment – Free Online Course