fix(origin): serve port 80 instead of redirecting to a certificate nobody can verify - #14
Merged
Merged
Conversation
…body can verify
The template redirected :80 to :443, with a comment saying the only
problem was a missing 443 block. That reasoning was incomplete: it
assumes the client can verify what it lands on, and the two biggest
classes cannot.
No CA will issue for an ending outside the DNS root, so the 443 block
presents a self-signed certificate. TronBrowser, moshpit-proxy and the
SDKs check it against the registry's published pin and are fine. curl and
a stock browser have no pin to check, so they reject it — and the
redirect leaves them nowhere:
curl chovy.hacker -L
curl: (60) SSL certificate problem: self-signed certificate
Through the gateway it is worse: pit.moshcode.sh forwards the status and
not the Location, so a visitor gets a 301 pointing nowhere at all.
Now :80 serves the site. Both ports serve it, neither redirects to the
other, and each client takes the one it can verify — pin-checking clients
still get TLS, everyone else gets the page instead of an error that reads
as "Moshpit is broken".
HTTPS-only remains right for a name in the public DNS. It is not
available for a name outside it, and pretending otherwise costs the
visitor the site.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
vu1nz Security Review0 finding(s) in PR #? No security issues found. |
This was referenced Aug 3, 2026
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.
This changes a line the template explicitly says to keep, so here is the argument.
The existing comment
The premise is that a 443 block makes the redirect safe. It does not, because it assumes the client can verify what it lands on.
Why stock clients cannot
No CA will issue for an ending outside the DNS root, so the 443 block presents a self-signed certificate. That is fine for TronBrowser,
moshpit-proxyand the SDKs — they check it against the registry's published pin, which is a stronger statement than a CA's. It is fatal for everyone else:Through the gateway it is worse:
pit.moshcode.shforwards the status without the Location header, so a visitor gets a 301 pointing nowhere at all.Both were reproduced on a live origin today.
The change
Port 80 serves the site. Both ports serve it, neither redirects to the other, and each client takes the one it can verify — pin-checking clients still get TLS, everyone else gets the page instead of an error that reads as "Moshpit is broken".
HTTPS-only is still right for a name in the public DNS. It is not available for a name outside it, and pretending otherwise costs the visitor the site.
Verified
Rendered with a real name and run through
nginx -t: syntax is ok.Why it matters more than one template
moshpit-reconcile.shruns this every 60s for every name pointed at a box, so this redirect is applied automatically to every Moshpit origin — and re-applied after anyone fixes a vhost by hand.