config: add Aliyun (Alibaba Cloud) CDN domain-fronting provider#10
Merged
Conversation
|
Caution Review failedPull request was closed or merged during review No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds ChangesAliyun CDN Domain-Fronting Provider
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Contributor
There was a problem hiding this comment.
Pull request overview
Adds an Aliyun (Alibaba Cloud) CDN provider configuration and an opt-in live test to validate end-to-end domain-fronting against real Aliyun edges (including TLS chain verification and ALPN-negotiated HTTP/2 behavior, when enabled via env var).
Changes:
- Added
aliyun-provider.yamlas a standaloneParseConfigYAML-compatible config containing Aliyun provider settings (trusted root, SNI selection, and seed masquerade IPs). - Added
aliyun_live_test.go, an opt-in (DOMAINFRONT_LIVE=1) live network test that loads the YAML, expands provider SNIs, dials edges using the library’s TLS path, and attempts a cross-org fronted request.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| aliyun-provider.yaml | Introduces Aliyun provider YAML config (trusted CA, fronting SNIs, host alias placeholders, masquerade seed list). |
| aliyun_live_test.go | Adds an opt-in live test that exercises Aliyun provider config against real CDN edges using the library’s dial/roundtrip path. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
myleshorton
force-pushed
the
fisk/aliyun-provider
branch
from
4aa05ca to
55ccbf1
Compare
Alibaba Cloud / Aliyun CDN edges route by the HTTP Host header (h1) / :authority (h2) and ignore the TLS SNI for origin selection, so a censor filtering on SNI sees only an innocent front domain (img.alicdn.com) while the request reaches the real target. Verified 2026-06-23 cross-organization: a TLS session bearing Alibaba's *.tbcdn.cn cert (SNI img.alicdn.com) reached Bilibili (s1.hdslb.com) and Momo (img.momocdn.com) origins purely by Host. This adds aliyun-provider.yaml: a complete, parseable Config with the GlobalSign Root CA - R3 (anchors the Alibaba leaf chain), a verified seed pool of edge IPs across three /24s, and frontingsnis driving img/gw/a .alicdn.com SNIs. hostaliases + testurl are placeholders until Lantern origins are onboarded as Aliyun CDN distributions (the edge silently drops non-customer Host values). aliyun_live_test.go (guarded by DOMAINFRONT_LIVE=1) drives the real roundTripper: every edge completes TLS + GlobalSign verification under the production Chrome_131 hello and fronts a cross-org Host over HTTP/2 (200). Depends on #9 (HTTP/2 fronting) — Aliyun negotiates h2. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…guard test - Set provider-level verifyhostname: img.alicdn.com so the SNI path enforces leaf hostname verification instead of chain-only (which would accept any GlobalSign-R3-chained cert). All masquerade edges serve Alibaba's *.tbcdn.cn cert (SAN *.alicdn.com), so the single value validates every rotating frontingsni (img/gw/a.alicdn.com). - Drop per-masquerade sni/verifyhostname: ExpandedProvider ignores them (it propagates the provider-level values), so listing them was misleading. - Guard the live test with require.Contains before indexing Providers["aliyun"] to fail clearly instead of a nil-deref panic if the key changes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…olders - The live test counted any HTTP 200 as success even if ALPN had fallen back to http/1.1, so it didn't actually prove the HTTP/2 fronting path. Now require that at least one cross-org front succeeded with proto=="h2" and an HTTP/2 response (frontedOverH2). - Lowercase the REPLACE-ME placeholder hostnames (replace-me.w.kunlunaq.com): ExpandedProvider doesn't lowercase alias values, and lowercase matches the README examples and avoids case-sensitive host routing surprises. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Check the http.NewRequestWithContext and io.ReadAll errors instead of discarding them; require a clean body read before counting a front as successful, so a truncated/failed response can't be miscounted. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Replace the REPLACE-ME placeholders with the real Aliyun DCDN accelerated domains, now created and validated end-to-end (2026-06-23): fronting each via img.alicdn.com returns byte-identical responses to the canonical origin. config.getiantem.org -> config.dcdn.getiantem.org api.getiantem.org -> api.dcdn.getiantem.org geo.getiantem.org -> geo.dcdn.getiantem.org update.getlantern.org -> update.dcdn.getiantem.org The hostalias value is the accelerated domain (the fronted Host), not the *.w.kunlungr.com edge CNAME — the edge vhosts on the accelerated domain. Each distribution is overseas-scope, origin = the raw iantem.io backend (bypassing Cloudflare) with back-to-origin SNI = origin and Host = service domain. testurl notes the 202-ping follow-up. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
myleshorton
force-pushed
the
fisk/aliyun-provider
branch
from
35e8508 to
5547e86
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@aliyun_live_test.go`:
- Around line 78-84: The close operations for res.conn and resp.Body are
ignoring their returned errors, which can hide I/O teardown issues and will fail
errcheck validation. Capture the error return values from both res.conn.Close()
at line 78 and resp.Body.Close() at line 84, then handle these errors
appropriately by either logging them with t.Logf or asserting they are nil using
error checks or if statements to ensure any close errors are properly reported
in the test output.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: bdf2e63f-017e-4b90-8834-092851e0fcc8
📒 Files selected for processing (2)
aliyun-provider.yamlaliyun_live_test.go
Capture and log the errors from res.conn.Close() and resp.Body.Close() in TestAliyunProviderLive rather than discarding them, matching the test's existing t.Logf diagnostics and satisfying errcheck. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Comment on lines
+61
to
+63
| # NOTE: These hostaliases and testurl are real, validated mappings. | ||
| # aliyun_live_test.go reads this file directly; if you intend placeholders, | ||
| # update the PR description and replace these with clearly marked REPLACE-ME values. |
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
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.
What
Add Alibaba Cloud (Aliyun) CDN as a domain-fronting provider — a third option alongside CloudFront and Akamai.
Why Aliyun works for fronting
Aliyun CDN edges route purely on the HTTP
Hostheader (HTTP/1.1) /:authority(HTTP/2) and ignore the TLS SNI for origin selection — the unrestricted domain-fronting behavior CloudFront/Google/Akamai removed in 2018. A censor doing SNI filtering sees only an innocent front domain (img.alicdn.com, core Taobao infrastructure that's costly to block).Verified 2026-06-23 (US vantage), cross-organization: a TLS session presenting Alibaba's
*.tbcdn.cncertificate (SNIimg.alicdn.com) reached the origins of three unrelated companies purely viaHost:Host:img.alicdn.com(Alibaba)www.taobao.comimg.alicdn.com(Alibaba)s1.hdslb.com(Bilibili)OK, 200img.alicdn.com(Alibaba)img.momocdn.com(Momo)x-tos-*headers)What's in the file
aliyun-provider.yamlis a complete,ParseConfigYAML-ableConfig(so it loads standalone for testing); thealiyun:block is what merges into the upstreamfrontedpipeline output.trustedcas— GlobalSign Root CA - R3, which anchors the Alibaba leaf chain (*.tbcdn.cn → GlobalSign GCC R3 OV TLS CA 2024 → R3). Confirmed to verify the live chain.frontingsnis.default—img/gw/a.alicdn.com, all covered by the shared*.tbcdn.cncert and provisioned CDN-wide.masquerades— a verified seed pool of edge IPs across three /24s, each confirmed to present the Alibaba cert.hostaliasesandtesturlareREPLACE-MEplaceholders. Two boundary conditions make this unavoidable today:Hostmust be an onboarded Aliyun CDN customer — a non-customer Host (e.g.www.example.com) is silently dropped. So Lantern must create its own Aliyun CDN distributions and map real origins to them.testurlmust return 202 on POST (theverifyWithPostvetting contract), which only a Lantern-controlled distribution can satisfy.Mapping real domains + the masquerade harvesting belong in the lantern-cloud config-generation pipeline (tracked separately).
Test plan
aliyun_live_test.go(guarded byDOMAINFRONT_LIVE=1; skipped in CI). Against the real Aliyun CDN, through the library's realroundTripper:i.e. every edge completes TLS + GlobalSign verification under the production Chrome_131 hello and fronts Bilibili over HTTP/2.
🤖 Generated with Claude Code
Summary by CodeRabbit
Release Notes
New Features
Tests