Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(gw): DNSLink names on https:// subdomains #7847

Merged
merged 3 commits into from
Jan 14, 2021

Conversation

lidel
Copy link
Member

@lidel lidel commented Jan 1, 2021

Closes ipfs/in-web-browsers#169, Closes ipfs/in-web-browsers#174
cc @aschmahmann @autonome @Gozala @gmasgras @mburns

👉 I marked this as P0 because we want dweb.link to run this patch when support for ipns://{dnslink-name} resolution lands in Brave stable (brave/brave-browser#10220). Without it, onboarding will include the TLS error, which is really bad UX. Ideally, we would include this in 0.8 (#7707).

TLDR

This PR enables users of public gateways to load DNSlink websites without TLS error described in ipfs/in-web-browsers#169.

It not only makes DNSLink websites more resilient, but makes it easier to resolve ipns:// URIs in Opera Mobile and Brave (when a public gateway is selected as a resolution method).

Details

  • This PR enables public subdomain gateways such as dweb.link to provide DNSLink hosting service over HTTPS with a
    standard single-level-wildcard TLS certificate.
    • Detailed problem statement and rationale for doing this can be found in TLS for DNSLink websites loaded via public subdomain gateways in-web-browsers#169
      • This PR implements "Option C" in a way that works with existing single-level-wildcard TLS certs present on the web
      • Subdomain gateway will redirect to inlined DNSlink name only when X-Forwarded-Proto: https is present (opt-in made by gateway operator), no additional configuration is needed.

How DNSlink name inlining works

Below is a real life example of a DNSlink name inlined into a single DNS label that works with a wildcard TLS cert for *.ipns.dweb.link:

/ipns/en.wikipedia-on-ipfs.org
ipns://en.wikipedia-on-ipfs.org
https://dweb.link/ipns/en.wikipedia-on-ipfs.org
https://en-wikipedia--on--ipfs-org.ipns.dweb.link 👈 a single DNS label, no TLS error

Use cases fixed by this PR

  • User wants to load my.v-long.example.com but the original HTTP server is down. The hostname has DNSLink set up.
    User should be able to load website not only from a local gateway, but any public one.
  • User of Brave [who does not run local node] or user of Opera Mobile tries resolve ipns:// URIs using public gateway (eg. dweb.link).
    • This PR enables page load via a public gateways: ipns://my.v-long.example.comhttps://dweb.link/ipns/my.v-long.example.com → (HTTP 301) → https://my-v--long-example-com.ipns.dweb.link

Problem statement and rationale for doing this can be found under
"Option C" at: ipfs/in-web-browsers#169

TLDR is:

`https://dweb.link/ipns/my.v-long.example.com` can be loaded from a
subdomain gateway with a wildcard TLS cert if represented as a single
DNS label: `https://my-v--long-example-com.ipns.dweb.link`
@lidel lidel added topic/gateway Topic gateway P0 Critical: Tackled by core team ASAP labels Jan 1, 2021
@lidel lidel requested review from autonome and aschmahmann January 1, 2021 21:19
@lidel lidel marked this pull request as ready for review January 4, 2021 11:35
@lidel lidel changed the title feat(gw): support inlined DNSLink names with TLS feat(gw): support DNSLink names at https:// subdomain gateways Jan 4, 2021
@lidel lidel changed the title feat(gw): support DNSLink names at https:// subdomain gateways feat(gw): DNSLink names on https:// subdomains Jan 4, 2021
Comment on lines +406 to +411
# DNSLink on Public gateway with a single-level wildcard TLS cert
# "Option C" from https://github.com/ipfs/in-web-browsers/issues/169
test_expect_success \
"request for example.com/ipns/{fqdn} with X-Forwarded-Proto redirects to TLS-safe label in subdomain" "
curl -H \"Host: example.com\" -H \"X-Forwarded-Proto: https\" -sD - \"http://127.0.0.1:$GWAY_PORT/ipns/en.wikipedia-on-ipfs.org/wiki\" > response &&
test_should_contain \"Location: https://en-wikipedia--on--ipfs-org.ipns.example.com/wiki\" response
Copy link
Member Author

@lidel lidel Jan 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR in action:

  1. User opens ipns://en.wikipedia-on-ipfs.org/wiki
  2. User agent (eg. web browser) resolves ipns:// URI via public gateway at https://example.com/ipns/en.wikipedia-on-ipfs.org/wiki which returns HTTP 301 redirect to https://en-wikipedia--on--ipfs-org.ipns.example.com/wiki if X-Forwarded-Proto: https is present.

Comment on lines +552 to +555
test_expect_success \
"request for {single-label-dnslink}.ipns.example.com with X-Forwarded-Proto returns expected payload" "
curl -H \"Host: dnslink--subdomain--gw--test-example-org.ipns.example.com\" -H \"X-Forwarded-Proto: https\" -sD - \"http://127.0.0.1:$GWAY_PORT\" > response &&
test_should_contain \"$CID_VAL\" response
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.. after redirect:
3. Inlined DNSLink name returns expected payload.

Copy link

@autonome autonome left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not familiar w/ the go code so needs a proper review from a go-ipfs person, but I didn't see any problems. couple of minor notes below.

core/corehttp/hostname.go Outdated Show resolved Hide resolved
core/corehttp/hostname_test.go Show resolved Hide resolved
core/corehttp/hostname.go Outdated Show resolved Hide resolved
This kinda enables to run their custom DNS resolver with custom
tlds/names that are independent from the public DNS network.
@aschmahmann aschmahmann merged commit 4ccb526 into master Jan 14, 2021
@aschmahmann aschmahmann deleted the fix/dnslink-in-subdomain-gw branch January 14, 2021 19:50
lidel added a commit to ipfs/in-web-browsers that referenced this pull request Feb 3, 2021
Simplify DNSLink handling:
ipfs/kubo#7847 will ship with go-ipfs 0.8.0
and is already supported at dweb.link
lidel added a commit to ipfs/in-web-browsers that referenced this pull request Feb 4, 2021
* docs: simplified DNSLink handling on subdomain gws

Simplify DNSLink handling:
ipfs/kubo#7847 will ship with go-ipfs 0.8.0
and is already supported at dweb.link

* style: replace code block with table
* docs: link to suborigin status
* docs: clarify types of content handled by gateways
* docs: simplify TLDR
kingwel-xie pushed a commit to kingwel-xie/go-ipfs that referenced this pull request Feb 5, 2021
hacdias pushed a commit to ipfs/boxo that referenced this pull request Jan 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P0 Critical: Tackled by core team ASAP topic/gateway Topic gateway
Projects
None yet
Development

Successfully merging this pull request may close these issues.

DNSLink on Opera Android does not load TLS for DNSLink websites loaded via public subdomain gateways
3 participants