fix(manage-server): scope TLS validation bypass to the health-check loop #5

Merged

amiryahaya merged 1 commit from fix/scope-tls-bypass-health-check into main

2026-07-24 14:55:11 +02:00

amiryahaya commented

2026-07-24 14:53:54 +02:00

Owner

[System.Net.ServicePointManager]::ServerCertificateValidationCallback = { $true } globally disabled certificate validation for all ServicePointManager-based HTTPS calls for the rest of the PowerShell session — not scoped to the specific self-signed loopback health-check connection it's meant for, and never reset afterward. Any later https:// Invoke-WebRequest call in the same session would silently inherit the same blanket bypass.

Traced both files' full remaining flow after this point: install.ps1's background setup-completion watcher runs as a completely separate Start-Process child (ServicePointManager state is per-process, so it never inherits the parent's override regardless), and upgrade.ps1 has no further HTTP calls at all after its health-check loop. So neither file currently has a live "later https call silently succeeds against an MITM" exploit path — but the anti-pattern is real: a future maintainer adding any https:// call later in either script would silently inherit the bypass with no warning.

Fix

A full CA-pinned SslStream rewrite (matching the agent installer's approach for its remote connection) wasn't applied here: this check is purely a loopback probe against a container the script itself just started — there's no untrusted network path to defend against (an attacker capable of hosts-file tampering to hijack localhost already needs the same admin privilege both scripts already require), so the added complexity buys little. Instead, resets the callback to $null immediately after the health-check loop in both install.ps1 and upgrade.ps1, scoping the bypass window to exactly the calls that need it.

Verification

Verified via PowerShell Core's own parser (no live Windows box in this environment): no syntax errors in either file
Independent code review pass completed: confirmed the "no live exploit path" claim by tracing both files' full control flow (including confirming the background watcher is a genuinely separate process, not a shared runspace), confirmed $null is .NET's actual default (full restoration, not a weaker no-op) and the reset is reached on every code path out of the loop, confirmed the loopback/no-untrusted-path reasoning holds given both scripts already require admin elevation — no findings

Fixes amiryahaya/triton#339

`[System.Net.ServicePointManager]::ServerCertificateValidationCallback = { $true }` globally disabled certificate validation for all `ServicePointManager`-based HTTPS calls for the rest of the PowerShell session — not scoped to the specific self-signed loopback health-check connection it's meant for, and never reset afterward. Any later `https://` `Invoke-WebRequest` call in the same session would silently inherit the same blanket bypass. Traced both files' full remaining flow after this point: `install.ps1`'s background setup-completion watcher runs as a completely separate `Start-Process` child (`ServicePointManager` state is per-process, so it never inherits the parent's override regardless), and `upgrade.ps1` has no further HTTP calls at all after its health-check loop. So neither file currently has a live "later https call silently succeeds against an MITM" exploit path — but the anti-pattern is real: a future maintainer adding any `https://` call later in either script would silently inherit the bypass with no warning. ## Fix A full CA-pinned `SslStream` rewrite (matching the agent installer's approach for its remote connection) wasn't applied here: this check is purely a loopback probe against a container the script itself just started — there's no untrusted network path to defend against (an attacker capable of hosts-file tampering to hijack `localhost` already needs the same admin privilege both scripts already require), so the added complexity buys little. Instead, resets the callback to `$null` immediately after the health-check loop in both `install.ps1` and `upgrade.ps1`, scoping the bypass window to exactly the calls that need it. ## Verification - Verified via PowerShell Core's own parser (no live Windows box in this environment): no syntax errors in either file - Independent code review pass completed: confirmed the "no live exploit path" claim by tracing both files' full control flow (including confirming the background watcher is a genuinely separate process, not a shared runspace), confirmed `$null` is .NET's actual default (full restoration, not a weaker no-op) and the reset is reached on every code path out of the loop, confirmed the loopback/no-untrusted-path reasoning holds given both scripts already require admin elevation — no findings Fixes amiryahaya/triton#339

amiryahaya added 1 commit

2026-07-24 14:53:54 +02:00

fix(manage-server): scope TLS validation bypass to the health-check loop 978142eb2c

[System.Net.ServicePointManager]::ServerCertificateValidationCallback
= { $true } globally disabled certificate validation for all
ServicePointManager-based HTTPS calls for the rest of the PowerShell
session — not scoped to the specific self-signed loopback health-check
connection it's meant for, and never reset afterward. Any later
https:// Invoke-WebRequest call in the same session would silently
inherit the same blanket bypass.

Traced both files' full remaining flow after this point: install.ps1's
background setup-completion watcher runs as a completely separate
Start-Process child (ServicePointManager state is per-process, so it
never inherits the parent's override regardless), and upgrade.ps1 has
no further HTTP calls at all after its health-check loop. So neither
file currently has a live "later https call silently succeeds against
an MITM" exploit path — but the anti-pattern is real: a future
maintainer adding any https:// call later in either script would
silently inherit the bypass with no warning.

A full CA-pinned SslStream rewrite (matching the agent installer's
approach for its remote connection) wasn't applied here: this check is
purely a loopback probe against a container the script itself just
started — there's no untrusted network path to defend against, so the
added complexity buys little. Instead, reset the callback to $null
immediately after the health-check loop in both install.ps1 and
upgrade.ps1, so the bypass window is scoped to exactly the calls that
need it.

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

Fixes amiryahaya/triton#339

amiryahaya merged commit 0c96f47b45 into main

2026-07-24 14:55:11 +02:00

amiryahaya referenced this pull request from a commit

2026-07-24 14:55:13 +02:00

Merge pull request 'fix(manage-server): scope TLS validation bypass to the health-check loop' (#5) from fix/scope-tls-bypass-health-check into main