Skip to content

Support SPP 9.0 TLS 1.3: pin HTTP/1.1 and add TLS version range (#650) - #653

Draft
DanPeterson wants to merge 2 commits into
mainfrom
danpeterson-tls13-http1-support
Draft

Support SPP 9.0 TLS 1.3: pin HTTP/1.1 and add TLS version range (#650)#653
DanPeterson wants to merge 2 commits into
mainfrom
danpeterson-tls13-http1-support

Conversation

@DanPeterson

Copy link
Copy Markdown
Contributor

Fixes #650.

Summary

SPP 9.0 enables TLS 1.3 and exposes an HTTP/2-capable binding. HTTP/2 disallows the post-handshake certificate request that client-certificate authentication depends on, so this pins HTTP/1.1 on all Safeguard REST calls, and adds an optional TLS version range for callers who want to constrain negotiation.

Changes

  • Pin HTTP/1.1 on every Safeguard REST call, including the A2A certificate-auth callers in a2acallers.psm1 (pure client-cert auth — the case most likely to break on 9.0's HTTP/2 binding). Applied via -HttpVersion 1.1 where available (PowerShell 7.3+); older PS7 and Windows PowerShell 5.1 already default to HTTP/1.1.
  • -MinimumTlsVersion / -MaximumTlsVersion (1.2 or 1.3) on Connect-Safeguard and Invoke-SafeguardMethod:
    • -MinimumTlsVersion 1.3 requires TLS 1.3, failing closed below it.
    • -MaximumTlsVersion 1.2 pins to TLS 1.2 as an interim measure.
    • Both together negotiate within an inclusive range; neither = today's default negotiation (unchanged).
    • Persisted in the session and inherited by later Invoke-SafeguardMethod calls.
    • PowerShell 7 applies the range per request via -SslProtocol; Windows PowerShell 5.1 applies it process-wide via ServicePointManager. Only TLS 1.2/1.3 are ever enabled (1.0/1.1 remain excluded).
  • Version bump to 8.5.0 (pipeline-templates/global-variables.yml + src/safeguard-ps.psd1, keeping the .99999 placeholder).
  • Unit tests for the version-set resolver and web-request preferences; README "TLS and HTTP behavior" section updated.

Validation

  • ./Invoke-PsLint.ps1 -Strict clean (src + test)
  • Module imports under PowerShell 7; new parameters present with ValidateSet 1.2/1.3
  • New Issue-650 Pester tests pass (the pre-existing Strips Tls10/Tls11 failures are unrelated and untouched)

Testing still needed (draft)

  • Verify against an 8.x appliance (regression: cert-auth, password-auth, A2A still work; default negotiation unchanged)
  • Verify against a 9.0 appliance (TLS 1.3 enabled): cert-auth over the HTTP/2-capable binding, -MinimumTlsVersion 1.3, and -MaximumTlsVersion 1.2
  • A2A credential retrieval against 9.0 with a client certificate

SPP 9.0 enables TLS 1.3 and exposes an HTTP/2-capable binding. HTTP/2
disallows the post-handshake certificate request that client-certificate
authentication depends on, so all Safeguard REST calls -- including the
A2A certificate callers in a2acallers.psm1 -- are pinned to HTTP/1.1.

Connect-Safeguard and Invoke-SafeguardMethod gain optional
-MinimumTlsVersion and -MaximumTlsVersion (1.2 or 1.3) to constrain the
negotiated TLS version and fail closed outside the range. The setting is
persisted in the session and inherited by later Invoke-SafeguardMethod
calls. On PowerShell 7 the range is applied per request via -SslProtocol;
on Windows PowerShell 5.1 it is applied process-wide via
ServicePointManager.

Bumps the base version to 8.5.0.
@DanPeterson
DanPeterson force-pushed the danpeterson-tls13-http1-support branch from 99b266e to c9abf96 Compare August 14, 2026 01:06
Connect-Safeguard always stores MinimumTlsVersion/MaximumTlsVersion in the
session hashtable, and both are empty when a connection is made without
explicit TLS pins (the default). Invoke-SafeguardMethod then inherited those
empty values into its own [ValidateSet("1.2","1.3")][string] parameters,
which throws "'' is not a valid value for the MinimumTlsVersion variable"
at assignment time. Because virtually every cmdlet routes through
Invoke-SafeguardMethod, this broke the module for any session that did not
pin a TLS version.

Guard both inheritance assignments so a value is only pulled from the
session when it is actually set, matching the existing IsNullOrEmpty guard
used before forwarding the bounds to a nested Connect-Safeguard.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support SPP 9.0 TLS 1.3: pin HTTP/1.1 and add optional TLS 1.3 enforcement

2 participants