Open the origin directly, and trust the store curl actually reads - #13
Merged
ralyodio merged 1 commit intoAug 3, 2026
Merged
Conversation
Copy link
Copy Markdown
Contributor
Sorry, something went wrong.
Two defects found by installing this on a real machine rather than by reading it. The proxy relayed every connection through the gateway. That only works if the gateway passes TLS through by SNI; pit.moshcode.sh terminates it, so every name presented the gateway's own certificate and the proxy refused all of them — correctly, and uselessly. Three different names refused for one identical presented key is the signature: refuse alt.2600: key mismatch, presented ErIMn03cxhS+... refuse chovy.hacker: key mismatch, presented ErIMn03cxhS+... refuse seo.rank: key mismatch, presented ErIMn03cxhS+... The registry already publishes each name's target, so the proxy now dials the origin and falls back to the gateway only when there is no target. This changes nothing about trust: the pin still decides whether the connection lives, so a target pointed somewhere hostile fails the same check. It removes a hop that has to be configured exactly right to work at all. Separately, moshpit-trust covered browsers and not the system CA store, so `curl <name>` still failed on a machine that had been set up — which reads as the scheme being broken rather than one store being missed. It now installs into the distribution's anchor directory and rebuilds the bundle, with a read-back that checks the bundle really contains the root: update-ca-certificates ignores a file whose name does not end in .crt, silently and successfully, and that is exactly the failure worth catching. Verified on the box: all four live names now serve over the stock configuration, TLSv1.3 hybrid-pq, with no gateway override and no local pin file. Known limitation: an override supplies pins and no target, so an override-pinned name still relays through the gateway. Overrides are for private grids that may have no registry, so they deliberately skip it; letting an override carry its own target is the follow-up. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Copy link
Copy Markdown
vu1nz Security Review0 finding(s) in PR #? No security issues found. |
Sorry, something went wrong.
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.
Two defects found by installing this on a real machine rather than by reading it.
1. Every connection went through a gateway that terminates TLS
The proxy relayed to pit.moshcode.sh:443, which only works if the gateway passes the connection through by SNI (ssl_preread). It terminates instead — so every name presented the gateway's own certificate and the proxy refused all of them. Correctly, and uselessly:
Three different names, one identical key. Anyone following the README hit this — the proxy looked broken while it was in fact doing its job.
The registry already publishes each name's target, so the proxy now dials the origin and falls back to the gateway only when there is no target.
This changes nothing about trust. The pin still decides whether the connection lives, so a target pointed somewhere hostile fails exactly the same check. It removes a hop that has to be configured precisely right to work at all.
Target parsing handles host, host:port, [v6]:port and bare IPv6 — 2604:a880::1 has plenty of colons and no port, so splitting on the first one would be wrong.
2. moshpit-trust never touched the store curl reads
It covered NSS and the macOS keychain. curl, wget, git and Node read /etc/ssl/certs, which it left alone — so curl <name> still failed with a self-signed certificate error on a machine that had been "set up". On a headless box it reported 0 of 1 set up and there was nothing it could do.
It now installs into the distribution's anchor directory (Debian, RHEL and Arch layouts, first match only) and runs the matching refresh.
The read-back checks the bundle contains the root, not merely that a file landed in a directory. That is the failure worth catching: update-ca-certificates ignores any file not ending in .crt — silently, exiting zero.
Verified
On the box, all four live names over stock configuration — no MOSHPIT_GATEWAY_HOST, no local pin file:
curl returns 200 for each with no -k. Suite: 61 pass, 0 fail (was 51).
Known limitation
An override supplies pins and no target, so an override-pinned name still relays through the gateway. Overrides exist for private grids that may have no registry at all, so skipping it is deliberate — letting an override carry its own target is the follow-up, not something to bolt on here.
🤖 Generated with Claude Code