Skip to content

Fixes breakage of resolving hostnames to ips on https#183

Closed
ospfranco wants to merge 1 commit into
mainfrom
fix-https-breakage-of-resolved-ips
Closed

Fixes breakage of resolving hostnames to ips on https#183
ospfranco wants to merge 1 commit into
mainfrom
fix-https-breakage-of-resolved-ips

Conversation

@ospfranco

Copy link
Copy Markdown
Collaborator

Fixes #182

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Pull request overview

Resolves the regression reported in issue #182 where resolveDNSHost caused HTTPS fetches to fail by rewriting the request hostname to an IP address (breaking TLS/SNI and certificate validation).

Changes:

  • Preserve the original hostname for HTTPS URLs when resolveDNSHost returns an IP, while still performing SSRF preflight validation.
  • Add a regression test ensuring HTTPS requests are not rewritten to an IP.
  • Document the HTTPS behavior in the SSRF section of the README.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File Description
README.md Documents that HTTPS requests keep the original hostname to avoid TLS/SNI breakage.
index.ts Updates getValidatedFetchUrl to skip hostname-to-IP rewrites for https: URLs.
tests/index.spec.ts Adds a test asserting HTTPS fetch URLs are not rewritten to the resolved IP.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread index.ts
Comment on lines +253 to +256
// Rewriting the hostname to a bare IP breaks TLS: the handshake sends the IP as
// the SNI server name and certificate validation fails, since certificates are
// issued for hostnames, not IPs. The resolved address is still used above (via
// throwOnLoopback) to block the request, so HTTPS requests keep their hostname.
Comment thread README.md

This might add some latency to your request but prevents loopback attacks.

Note: for `https://` URLs the request is still made against the original hostname (not the resolved IP), since TLS validates the certificate and SNI against the hostname. The resolved address is only used to detect and block loopback/private targets before the request is made.
@ospfranco

Copy link
Copy Markdown
Collaborator Author

yeah, welp, I guess this solution doesn't work.

@ospfranco ospfranco closed this Jul 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4.0.4: resolveDNSHost rewrites the fetch URL to the resolved IP, breaking TLS (SNI/cert mismatch) for all HTTPS URLs

2 participants