• Contact Us

    We will get back to you as soon as possible.

  • We do not collect personal information except to the extent you provide that information to use through email, your web browser or through our contact forms. We will not share, sell or otherwise provide non-public information to others without your consent.

SIGN UP FOR OUR NEWSLETTER

  • We do not collect personal information except to the extent you provide that information to use through email, your web browser or through our contact forms. We will not share, sell or otherwise provide non-public information to others without your consent.

TLS Remediation – Finally Uncovered
Published on September 19, 2020
TLSHeader.png

Hey guys – me again harping on about TLS. There happens to be a number of incredibly smart men and women out there working diligently to eliminate weak TLS protocols. As an added bonus to this whole effort, this effort will also disable certain weak cryptographic ciphers.

With that said, let’s clearly, officially and resoundingly answer, once and for all, what is our end goal (or product) to all this offical sounding talk of “TLS remediation” – the goal is literally the safe and secure removal of both Client initiated and Server listening TLS protocols – perhaps tomorrow, it’ll mean something different – but today, it means the removal of all the old insecure stuff whereby enforcing all the new secure goodies.

Notice my little “SAFE” plug above – Yes, safe actually means exactly what it says. It is performing remediation actions without breaking applications or impacting your user population. Both can be very (extremely) expensive propositions. I’ve never been overly-fond of the “Scream-Test” approach – meaning waiting and listening for some anticipated & distant wretched scream to determine whether my change was successful. I’ve also never agreed with the random mandates of an ill-informed and pompous security manager who randomly disables (or instructs others) some setting in order to increase his score card rating.

I’ve never been overly-fond of the “Scream-Test” approach – meaning waiting and listening for some anticipated & distant wretched scream to determine whether my change was successful.

Regardless of the challenge – get down in the mud, look and understand each of the pertinent elements. For goodness sake, don’t wait for someone else to. Do the research yourself. Find out how this whatchamahoo operates. Ask lots of questions. Do your best to uncover and determine all the aspects and specifics – and do it quickly. After all, there’s no better way to solve a problem than confronting and exploring its components.

Anyway, in order to safely and securely navigate and accomplish TLS Remediation – yes, the task at hand – it does require a whole new set of goggles and address to the situation. I’ve witnessed many per se “Forrest Gump” their way through remediation activities without having the slightest clue what they were doing. Umm… Yeahh…. Let’s just nod politely and continue…

So yes – this activity does require taking a fresh-new look at the challenge ahead with the disposition that there just might be something here you might not know – ouch. To some, this mere idea or admittance can cause severe ego-bruising. To others willing to really get down, confront and inspect the scene can literally prevent a resume generating event (RGE). With one particular client, this information saved the business dozens of jobs and hundreds of millions of dineros (aka: moolah, cash, dollars, etc..).

With that said, let’s get down into the details. All efforts have been made to keep this ruthlessly simple. If the material herein is something you’re already familiar or have had previous contact with, that’s a good sign. Please, just keep reading. note: the following has been extracted from one of my Powerpoint Decks concerning the subject.

Just reiterate, our goal is: safely enacting or enabling business controls, across all systems, which securely level-sets TLS Protocols eliminating insecure protocols (see below). Doing so prevents tampering, unexpected and random insecure behavior.

Important: TLS Remediation has a specific order. Knowing and understanding the elements will ensure remediation is simple and effective.

TLS Remediation – Client & Server Connections

  • Client’ services initiate connections to servers (refers to the source where network traffic is initiated or generated) – all systems initiate client connections (e.g. Linux, Win10, mobile devices, Server 2016, etc.)
  • Server’ listening services receive client connections or requests (refers to the receipt point or respondent of communication initiated by a client) – all systems listen for client connections (e.g. Linux, Win10, mobile devices, Server 2016, etc.)

    TLS Remediation – Dependencies & Behavior

  • Client’ Services negotiate communications with Server Services
  • Server’ Services listen and negotiate Client initiated sessions
  • The highest supported TLS version is always preferred by the operating system (link)

Important Caveat: Although the third bullet above remains true, as you are about to see, application-behavior (or laughingly called misbehavior) can cause unpredictable, random and insecure behavior.

TLS Remediation – Application Behavior

  • Applications are installed and utilized on both Workstations & Servers. (Workstations commonly have a number of installed applications. Typically fewer, Servers likewise maintain a number of applications)
  • Microsoft Client-applications are commonly written & compiled with .NET
  • Every .NET compiled client-application maintains its own built-in, unique & defined set of TLS protocol instructions and behavior(s)

Important: Differing versions of .NET client applications explicitly instruct the operating system (or SCHANNEL) what and how to negotiate TLS

  • The installed version of .NET Framework Runtime is not relevant to your TLS remediation efforts

TLS Remediation – Common Approach (not recommended)

Target: Windows Servers – Level-Set TLS

  • Disable SSL 2.0, 3.0 and TLS 1.0 – CLIENT & SERVER protocol setting

Anticipated Result:

  • From Client: .NET client-application fails to authenticate with the server
  • From Server: Application fails internally

Root Cause: .NET applications were not properly remediated prior to disabling TLS  (negotiation mismatch)

Solution:  Globally remediate all .NET applications prior to disabling TLS via SCHANNEL (Client & Server)

Note: This example and illustration assumes a .NET version 4.5.2 application behavior. This also assumes the .NET application has not been properly remediated.

TLS Remediation – Recommended Overview Approach

Prior to any TLS protocol modifications of any Domain Controllers or any Client/Server TLS protocols, remediate all .NET and WinHTTP applications. Once complete, remediate Client TLS protocols, then the Server’s TLS protocol setting. Do not vary the order of any of the following remediation phases:

  • Phase 1: – Remediate Client Applications (.NET, WinHTTP, etc.)
  • Phase 2: – Remediate Client TLS Settings
  • Phase 3: – Remediate Server TLS Settings

Note: As mentioned in this article, “Windows 8.1, Windows Server 2012 R2, Windows 10, Windows Server 2016, and later versions of Windows natively support TLS 1.2 for client-server communications over WinHTTP” – it is still recommended to level-set WinHTTP to use TLS 1.2.

TLS Remediation – Recommended Overview Phases

Phase 1: Remediate Client Applications (TLS)

  1. Remediate .NET Applications (3.5 – 3.5.1 & 4.0 – 4.8) – Level-set designated registry settings forcing .NET Apps to negotiate TLS 1.2 and/or rely on the OS to negotiate TLS
  2. Remediate WinHTTP Applications – Level-Set designated registry settings forcing WinHTTP Apps to negotiate TLS 1.2

Scope: All Windows Systems – e.g. Workstations & Server

Important: Continue only with phase 2 once all local client applications have been confirmed remediated – ensures all client applications collectively negotiate using TLS 1.2

Phase 2: Remediate TLS Client Settings

  1. Disable TLS 1.0 Client Settings Only
  2. Disable TLS 1.1 Client Settings Only

Scope: All Systems and/or appliances – e.g. Apple, Mobile, Win10, Firewalls, Network Switches, Wireless APs, Linux, Windows Servers, etc.

IMPORTANT:

  • Continue onto phase 3 once all local Client initiated TLS setting have been confirmed fully remediated
  • Begin phase 3 once all remote Client initiated TLS setting have been confirmed fully remediated

Phase 3: Remediate TLS Server Settings

  1. Disable TLS 1.0 Server Settings Only
  2. Disable TLS 1.1 Server Settings Only

Scope: All Systems and/or appliances – e.g. Apple, Mobile, Win10, Firewalls, Network Switches, Wireless APs, Linux, Windows Servers, etc.

Note: The above is a Microsoft approved remediation plan for ADFS – this however is only a summary. It is assumed between each above step, sufficient soak time, monitoring and QA would be allotted.

TLS Remediation – Additional Recommendations

It is recommended to proactively address weak TLS usage by removing TLS 1.0/1.1 dependencies in the environment (e.g. .NET Apps), and then disabling TLS 1.0/1.1 at the operating system (i.e. SCHANNEL). Given the length of time TLS 1.0/1.1 has been supported by the software industry, it is highly recommended that any TLS 1.0/1.1 deprecation plan include the following:

  • Application code analysis to find/fix hardcoded instances of TLS 1.0/1.1
  • Network endpoint scanning and traffic analysis to identify operating systems using TLS 1.0/1.1 or older protocols
  • Full regression testing through your entire application stack with TLS 1.0/1.1 and all older security protocols disabled
  • Migration of legacy: operating systems to versions capable of negotiating TLS 1.2 & development libraries/frameworks to versions capable of negotiating TLS 1.2
  • Compatibility testing across operating systems used by your business to identify any TLS 1.2 support issues
  • Coordination with business partners and customers to notify them of your move to deprecate TLS 1.0/1.1
  • Understanding which clients may be broken by disabling TLS 1.0/1.1

Related Articles:

I would love your feedback – please leave a comment. More to come.

Warmest Regards,

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