Support TLS 1.3 by default with optional min/max TLS enforcement (#240) - #242
Draft
DanPeterson wants to merge 1 commit into
Draft
Support TLS 1.3 by default with optional min/max TLS enforcement (#240)#242DanPeterson wants to merge 1 commit into
DanPeterson wants to merge 1 commit into
Conversation
Stop hard-pinning SslProtocols.Tls12 so connections negotiate the best available protocol (TLS 1.3 where the OS and appliance support it) via SslProtocols.None. Add optional minTlsVersion/maxTlsVersion (SafeguardTlsVersion?) parameters across all Connect and A2A.GetContext overloads, the RSTS login helpers, and the PKCE, Browser, DeviceCode, and GuiLogin modules, mirroring the PySafeguard min/max paradigm. The resolved protocol flows through the HTTP client, event listeners, and A2A SignalR connections. HTTP/1.1 behavior is unchanged.
petrsnd
marked this pull request as draft
August 17, 2026 20:36
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #240. SafeguardDotNet previously hard-pinned
SslProtocols.Tls12on every HTTP and SignalR connection, which prevented TLS 1.3 from ever being negotiated — even against SPP 9.0 appliances that support it.This PR stops pinning TLS 1.2 and instead lets the OS negotiate the best mutually supported protocol (
SslProtocols.None), so TLS 1.3 is used automatically where the client OS and appliance support it. HTTP/1.1 behavior is unchanged.It also adds optional TLS enforcement via
minTlsVersion/maxTlsVersionparameters, mirroring the min/max paradigm proposed for PySafeguard so the SDKs stay consistent.What changed
SafeguardTlsVersion { Tls12, Tls13 }and internalTlsVersionMapperthat maps an optional min/max range ontoSslProtocols(both null →None; validates min ≤ max).minTlsVersion/maxTlsVersion(SafeguardTlsVersion?, defaultnull= negotiate) appended to:Safeguard.ConnectoverloadsSafeguard.A2A.GetContextoverloadsAgentBasedLoginUtilsRSTS login helpersSslProtocolsis stored on the authentication mechanism and reused consistently by the HTTP client, event listeners, and A2A SignalR connections.README.md, plusAGENTS.md, api-patterns, and a2a-workflow skill updates.Usage
Testing
SafeguardDotNet.Core.slnbuilds with 0 warnings / 0 errors.SafeguardDotNet.Framework.sln(GuiLogin) builds.TlsVersionMappertests covering the negotiate default, single-bound pinning, full range, and the min > max error.Compatibility notes
minTlsVersion: SafeguardTlsVersion.Tls12to preserve the old floor.