Hacker News Reader

Comment by qwertox | Hacker News Reader

> If the hostname is detected to be longer than 255 bytes, curl switches to local name resolving and instead passes on the resolved address only to the proxy.

This sounds like an issue in itself, even if it is intended. Is that max length of the hostname a limitation of SOCKS5?

Let's assume you're using TOR through a SOCKS5 proxy, then any tool which uses libcurl will perform a local host lookup upon a https call (or redirect) to a long hostname, like one with a dynamically assigned UUID in a subdomain.

View on HN

DNS names are limited to 255 octets or less by RFC1035 (and if you get into the nitty gritty, only 253 bytes really, maybe 254 if you include the trailing dot that is commonly elided) I don't think that limit is relaxed by newer DNS RFCs.

I recommend programs using Tor to be run in an empty network namespace then set http/HTTPS/ALL_PROXY to a Unix domain socket created in torrc (or use socat to get it on the namespaces' 127.0.0.1 if not supported by the library), to avoid accidentally misconfiguring programs if their proxy settings are bad or you run a statically linked binary with torsocks.

Note that they no longer do this fallback to local name resolving:

From the advisory:

  Starting in curl 8.4.0, curl no longer switches to local resolve mode if the name is too long but is instead rightfully returning an error.

They changed the behaviour and will now error. Sounds like a protocol limitation

Yes, it is a protocol limitation. The hostname length field in a SOCKS5 request is a single byte, whence the maximum length. As explained in the write-up, curl now returns an error in that specific condition, which seems a more reasonable thing to do.

Reply on news.ycombinator.com