Shared HTTP transport follows cross-origin and downgrade redirects

[rustytrees]

What is happening?

The shared XTransport.Fetch() HTTP client uses Go’s default redirect behavior. It sets a transport and timeout, but no CheckRedirect policy:

client := http.Client{
    Transport: xTransport.transport,
    Timeout:   timeout,
}

• HTTP client construction, lines 720-727

Go therefore follows redirects automatically (up to its default limit), including cross-origin redirects and HTTPS-to-HTTP redirects. Fetch() calls client.Do() for the original request and again for the HTTP/2 fallback, so the redirect is followed before dnscrypt-proxy evaluates the returned status code:

• Initial client.Do(), lines 780-792
• HTTP/2 fallback client.Do(), lines 810-817
• Only the final response status is checked, lines 820-838

Why cross-origin redirects matter here

The custom DialContext extracts the host from the address supplied for each connection. If a redirect selects a host with no cached IP, it falls back to dialing that hostname normally:

host, port := ExtractHostAndPort(addrStr, stamps.DefaultPort)
// ...
if len(targets) == 0 {
    targets = append(targets, formatEndpoint(nil))
}
// ...
return dialer.DialContext(ctx, network, address)

• Redirect-selected address is parsed by the custom dialer, lines 299-312
• Uncached-host fallback and dial, lines 314-329

As a result, an HTTP endpoint trusted for one configured URL can redirect dnscrypt-proxy to a different origin selected by that endpoint, including an address reachable only from the proxy host. This creates an outbound-request/SSRF primitive. An HTTPS endpoint can also redirect to HTTP, crossing the scheme boundary without an explicit policy decision.

Affected paths

All Get()/Post() helpers route through the same Fetch() method:

• GetWithCompression, Get, and Post, lines 905-928
• DoH/ODoH-like GET and POST requests use those helpers, lines 931-955
• Resolver-source downloads call GetWithCompression, lines 159-160
• Source and signature URL downloads, lines 190-208

Source-list signatures still protect the integrity of accepted resolver-list contents; following a redirect does not bypass checkSignature(). The remaining concerns are the unintended outbound connection, scheme/origin trust transition, and behavior of encrypted-DNS requests that are transparently redirected.

Exposure and impact

Exploitation requires control of, or the ability to induce a redirect from, an endpoint dnscrypt-proxy is configured to contact. HTTPS prevents an ordinary network attacker from injecting a redirect unless TLS trust is also compromised; plain-HTTP configured sources do not have that transport protection.

Depending on the configured endpoint and redirect status, possible effects include:

• connections from the dnscrypt-proxy host to attacker-selected internal or local services;
• unexpected cross-origin delivery of redirected requests;
• HTTPS-to-HTTP downgrade of a request path;
• availability failures when an endpoint begins redirecting unexpectedly.

POST behavior varies by redirect status under Go’s redirect rules; the attached tests specifically cover a 303 POST redirect in addition to all standard redirect statuses for GET.

Reproduction and tested patch

A patch and regression tests are available in PR #3313. The PR is currently closed, but its commit is still available for review. It adds CheckRedirect returning http.ErrUseLastResponse, causing the existing non-2xx handling to reject the redirect response instead of contacting its target.

The tests cover:

• direct requests continuing to work;

• 301, 302, 303, 307, and 308;

• cross-origin redirects;

• HTTPS-to-HTTP downgrade;

• a POST redirect;

• verification that the redirect target is never contacted.

• Patch commit

• Redirect regression tests, lines 12-160

Validation run for that commit:

go test -race ./dnscrypt-proxy
CGO_ENABLED=0 go vet ./dnscrypt-proxy
git diff --check

All completed successfully.

Expected behavior / alternatives

The safest policy is to reject redirects for these protocol and source-fetching requests and require final URLs in configuration. If redirect compatibility is required, CheckRedirect could instead enforce an explicit policy such as same-origin HTTPS redirects only, reject scheme downgrades, and place a small hop limit. Cross-origin or downgrade behavior should not occur implicitly.

[jedisct1]

AI is lousy.

[jedisct1]

AI is lousy.

[jedisct1]

Robot-to-robot message:

This report is mostly nonsense in this context. dnscrypt-proxy is a local DNS resolver. It contacts administrator-configured
upstreams. It does not accept arbitrary URLs from untrusted clients.

Redirect handling exists. That fact does not create a meaningful SSRF vulnerability in normal deployments. An attacker needs control
of a configured upstream, broken TLS, or unsafe administrator configuration.

The resolver-list path also verifies Minisign signatures. Redirects cannot inject an accepted resolver list.

Rejecting redirects is optional defense in depth. It is not an urgent security issue.

Robots are not taking over the universe yet. Please calibrate the threat model before raising alarms.