Hotfix: TLS 1.1/1.0 deprecation (June 30, 2023)

mattborja commented 1 year ago

Description

Adds support for deployers to specify in application configuration which client TLS version to use when connecting to Duo API.

Usage

Review the desired SecurityProtocolType enum fields available in your .NET environment (version specific) and add a new DuoAPI_SecurityProtocolType entry to theappSettings section.

For example, under .NET 4.6 where the only usable enum of TLS 1.2 is supported (see note below), the following is provided as a working example:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <!-- ... -->

  <appSettings>
    <!-- ... -->

    <add key="DuoAPI_SecurityProtocolType" value="Tls12"/>
  </appSettings>
</configuration>

Note: SystemDefault does not exist before .NET 4.7 and Tls13 does not exist before .NET 4.8. Therefore, TLS 1.2 is the default version hard-coded into this change as a backwards compatibility option for applications still running under .NET 4.6.

Motivation and Context

This commit resolves TLS connection issues following deprecation of TLS 1.0/1.1 announced by duo to be effective June 30, 2023.

How Has This Been Tested?

Changes were tested locally, verified against customer's Duo Admin interface, and tested/accepted for production release by customer UAT group.

Types of Changes

[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

AaronAtDuo commented 1 year ago

@mattborja thanks for the PR and I like the idea, once we get CI passing. I did have a couple questions, but I am not even remotely a .NET developer, so please bear with me if these are silly:

1) Is use of the ConfigurationManager something most .NET devs will be familiar with? Or would it be helpful to provide a comment and/or example of how to use this new feature?

2) On my "nice to have some day" list is to convert this to a .NET Standard (or Core) library (i.e. move off .NET Framework so it can be cross-platform); is the ConfigurationManager something that's Framework specific?

mattborja commented 1 year ago

@AaronAtDuo Sorry for the delayed response. Long day.

@mattborja thanks for the PR and I like the idea, once we get CI passing. I did have a couple questions, but I am not even remotely a .NET developer, so please bear with me if these are silly:

The only silly questions in my book are the ones people are too proud to ask.

Is use of the ConfigurationManager something most .NET devs will be familiar with? Or would it be helpful to provide a comment and/or example of how to use this new feature?

ConfigurationManager is widely known and documented as a Microsoft-native namespace (System.Configuration). With exception to sensitive configuration, secrets, et. al. that may be stored separately, anyone shipping App.config or Web.config for managing application settings (i.e. <appSettings />) will generally be using ConfigurationManager to load those settings for runtime use.

On my "nice to have some day" list is to convert this to a .NET Standard (or Core) library (i.e. move off .NET Framework so it can be cross-platform); is the ConfigurationManager something that's Framework specific?

You will find ConfigurationManager all throughout the various iterations of .NET, all the way down to .NET Framework 2.0. See ConfigurationManager Class at Microsoft Learn for additional examples.

There are also other ways configuration can be implemented in .NET for a class library like this. My goal for this change set was to keep it simple and provide accompanying documentation on how developers would merely extend their existing appSettings section with the additional configuration setting supported (DuoAPI_SecurityProtocolType). It's a simple way of configuring the library without bootstrapping too much. What is especially useful with exposing this enum as a configuration setting in this manner is that we evade .NET version-specific enums that aren't available in lower versions (as you know), by leaving it up to the developer to simply select the one right for their environment. I'd hard code SystemDefault as the default for this library, but that's not even available until 4.7 or so.

AaronAtDuo commented 1 year ago

@mattborja I love both those answers! Thanks.

duosecurity / duo_api_csharp