fix(dns): a proxy this run started is a proxy it can trust - #481
Merged
Conversation
Proxy detection asked the proxy for a certificate under `a.<ending>`, and the
proxy will not present one for a name with no key published in the registry.
That refusal is deliberate — it produces a TLS failure a browser can explain
rather than a reset mid-request — and `dns enable` has no way to invent a name
somebody has registered, because the registry lists endings and not names.
`a.<ending>` is the best it could construct, and that is precisely the shape the
proxy refuses.
So the check could not pass on a correctly configured machine. Three lines
apart, both true as written:
ok proxy holds 127.0.0.1:443
-- no pinned-TLS proxy on this machine
The bridge was then started without proxy mode, so every Moshpit name answered
its origin directly and a stock client got a certificate no CA had signed — on a
machine that had, in the same run, installed the proxy, started it, watched it
take the port, and installed the local root into the system trust store.
v0.88.0 made the probe name parseable, which moved the failure from
ERR_INVALID_URL to ERR_TLS_CERT_ALTNAME_INVALID and no further: a name that
parses is still a name with no pin.
The probe was the wrong instrument. It exists for a proxy that something else
installed, where the question is genuinely open. It is not the question here:
this run wrote the unit, restarted it, and confirmed the port held. That is
stronger evidence of whose proxy it is than any handshake, so it is used, and
the probe is kept for the case it was written for.
Three tests, driving `dns enable` rather than the helper: a proxy this run
started turns proxy mode on and the bridge is checked to have actually been told
(`proxy: "127.0.0.1"` — without that names still answer their origin); a proxy
it did not start is still probed; and no proxy at all still brings DNS up,
because an optional component must never cost a machine its resolver.
Suite: 2768 tests, 0 failures.
Known and not fixed here: a bridge that is already running keeps the mode it
started with, so on a machine where one is up this takes effect on the next
restart of it rather than immediately.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ThnQwoieWt8VR6N7gtgnhp
ThreatCrush Security Scan1 finding(s) in the 2 file(s) this pull request changes. HIGH/CRITICAL: 1
90 pre-existing finding(s) elsewhere in the repository — **HIGH/CRITICAL**: 7 | **MEDIUM**: 73 | **LOW**: 10Not introduced by this pull request. The full set is in the Security tab.
…and 70 more. Full results in the Security tab. Snippets are redacted; ThreatCrush never prints matched credential material. |
Merged
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
1 participant
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.
Proxy detection asked the proxy for a certificate under
a.<ending>. The proxy will not present one for a name with no key published in the registry — deliberately, so a browser gets a TLS failure it can explain rather than a reset mid-request. Anddns enablecannot invent a name somebody registered: the registry lists endings, not names.a.<ending>is the best it could construct, and that's exactly the shape the proxy refuses.So the check could not pass on a correctly configured machine. Three lines apart, both true as written:
The bridge was then started without proxy mode, so every Moshpit name answered its origin and a stock client got a certificate no CA had signed — on a machine that had, in the same run, installed the proxy, started it, watched it take the port, and installed the local root into the system trust store.
v0.88.0 made the probe name parseable, which moved the failure from
ERR_INVALID_URLtoERR_TLS_CERT_ALTNAME_INVALIDand no further. A name that parses is still a name with no pin.The probe was the wrong instrument
It exists for a proxy that something else installed, where the question is genuinely open. That isn't the question here: this run wrote the unit, restarted it, and confirmed the port held. That's stronger evidence of whose proxy it is than any handshake.
So that's used, and the probe is kept for the case it was written for.
Tests
Three, driving
dns enableitself rather than the helper:proxy: "127.0.0.1"), without which names still answer their originSuite: 2768 tests, 0 failures.
Known, not fixed here
A bridge that is already running keeps the mode it started with. On a machine where one is up, this takes effect on the next restart of the bridge rather than immediately.
🤖 Generated with Claude Code
https://claude.ai/code/session_01ThnQwoieWt8VR6N7gtgnhp