fix(agent/get.ps1): remove dead ServicePointManager.SecurityProtocol line (v1.3.9) #3

Merged

amiryahaya merged 1 commit from fix/dead-tls-protocol-line-preflight into main

2026-07-24 14:23:50 +02:00

amiryahaya commented

2026-07-24 14:21:12 +02:00

Owner

commit 72a118a ("force TLS 1.2 for manage server download") added [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]3072 to both the download function and Invoke-Preflight when the download function still used Invoke-WebRequest/ServicePointManager. The very next commit (ef1c2ee) rewrote the download function to use raw SslStream and correctly removed the now-useless line from it — but the same dead line was never removed from Invoke-Preflight, which had already been using SslStream since its introduction and thus never benefited from it in the first place. SslStream.AuthenticateAsClient(string) ignores ServicePointManager entirely and negotiates via OS/Schannel default protocol selection.

On a hardened Windows host where TLS 1.2 has been disabled at the Schannel/registry level, this line gave a false impression that TLS 1.2 was being pinned when it actually wasn't, for either SslStream call in the file.

Fix

Removed rather than replaced with explicit protocol enforcement, to match the sibling Invoke-DownloadFromManageServer's own AuthenticateAsClient call — neither SslStream call site in this file pins a protocol version explicitly; both rely on OS/Schannel defaults. Adding enforcement to only one of the two would introduce a new inconsistency, not fix an existing one — if real TLS-version pinning is wanted, it should be a separate follow-up touching both call sites via the 4-arg AuthenticateAsClient overload.

Verification

Verified via PowerShell Core's own parser (no live Windows box in this environment, consistent with prior fixes in this repo's history): no syntax errors
Independent code review pass completed — confirmed the dead-code claim against actual .NET docs (SslStream.AuthenticateAsClient(String)'s remarks make no mention of ServicePointManager; that property only affects HttpWebRequest/FtpWebRequest/SmtpClient), confirmed no other dead ServicePointManager references remain in this file, no findings

Fixes amiryahaya/triton#337

commit 72a118a ("force TLS 1.2 for manage server download") added `[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]3072` to both the download function and `Invoke-Preflight` when the download function still used `Invoke-WebRequest`/`ServicePointManager`. The very next commit (ef1c2ee) rewrote the download function to use raw `SslStream` and correctly removed the now-useless line from it — but the same dead line was never removed from `Invoke-Preflight`, which had already been using `SslStream` since its introduction and thus never benefited from it in the first place. `SslStream.AuthenticateAsClient(string)` ignores `ServicePointManager` entirely and negotiates via OS/Schannel default protocol selection. On a hardened Windows host where TLS 1.2 has been disabled at the Schannel/registry level, this line gave a false impression that TLS 1.2 was being pinned when it actually wasn't, for either `SslStream` call in the file. ## Fix Removed rather than replaced with explicit protocol enforcement, to match the sibling `Invoke-DownloadFromManageServer`'s own `AuthenticateAsClient` call — neither `SslStream` call site in this file pins a protocol version explicitly; both rely on OS/Schannel defaults. Adding enforcement to only one of the two would introduce a new inconsistency, not fix an existing one — if real TLS-version pinning is wanted, it should be a separate follow-up touching both call sites via the 4-arg `AuthenticateAsClient` overload. ## Verification - Verified via PowerShell Core's own parser (no live Windows box in this environment, consistent with prior fixes in this repo's history): no syntax errors - Independent code review pass completed — confirmed the dead-code claim against actual .NET docs (`SslStream.AuthenticateAsClient(String)`'s remarks make no mention of `ServicePointManager`; that property only affects `HttpWebRequest`/`FtpWebRequest`/`SmtpClient`), confirmed no other dead `ServicePointManager` references remain in this file, no findings Fixes amiryahaya/triton#337

amiryahaya added 1 commit

2026-07-24 14:21:12 +02:00

fix(agent/get.ps1): remove dead ServicePointManager.SecurityProtocol line (v1.3.9) e11f5ae93e

commit 72a118a ("force TLS 1.2 for manage server download") added this
line to both the download function and Invoke-Preflight when the
download function still used Invoke-WebRequest/ServicePointManager.
The very next commit (ef1c2ee) rewrote the download function to use
raw SslStream and correctly removed the now-useless line from it — but
the same dead line was never removed from Invoke-Preflight, which had
already been using SslStream since its introduction and thus never
benefited from ServicePointManager.SecurityProtocol in the first
place. SslStream.AuthenticateAsClient(string) ignores
ServicePointManager entirely and negotiates via OS/Schannel default
protocol selection.

On a hardened Windows host where TLS 1.2 has been disabled at the
Schannel/registry level, this line gave a false impression that TLS
1.2 was being pinned when it actually wasn't, for either SslStream
call in the file.

Removed rather than replaced with explicit protocol enforcement, to
match the sibling Invoke-DownloadFromManageServer's own
AuthenticateAsClient call — neither SslStream call site in this file
pins a protocol version explicitly; both rely on OS/Schannel defaults.
Adding enforcement to only one of the two would be an inconsistency
this diff doesn't intend to introduce.

Verified via PowerShell Core's own parser (no live Windows box in this
environment): no syntax errors introduced.

Fixes amiryahaya/triton#337