bitreq: add SOCKS5 proxy support#533
bitreq: add SOCKS5 proxy support#533FreeOnlineUser wants to merge 1 commit intorust-bitcoin:masterfrom
Conversation
FreeOnlineUser
force-pushed
the
socks5-proxy
branch
from
5b283bb to
76d3875
Compare
tnull
left a comment
tnull
left a comment
There was a problem hiding this comment.
Took a first very high-level look.
| } | ||
| Some(proxy) => { | ||
| // do proxy things | ||
| // HTTP CONNECT proxy |
There was a problem hiding this comment.
I think we should be good to just drop the HTTP proxy behavior? Not sure anybody is going to use that, and it might make things simpler?
There was a problem hiding this comment.
HTTP CONNECT is what payjoin originally requested in #472, so I'd keep it. They serve different use cases: SOCKS5 for Tor/general proxying, HTTP CONNECT for corporate forward proxies and HTTPS tunneling. Happy to refactor if the maintainers agree it should go, but wanted to flag the other stakeholders first.
| /// let request = bitreq::post("http://example.com").with_proxy(proxy); | ||
| /// ``` | ||
| /// | ||
| pub fn new_socks5<S: AsRef<str>>(proxy: S) -> Result<Self, Error> { |
There was a problem hiding this comment.
Note that Tor (mis-)uses user credentials to trigger circuit rebuilding/stream isolation. So we probably want to allow for an interface that at least lets the user refresh/change the credentials freely on the Proxy object, so that subsequent connections are using a new circuit.
There was a problem hiding this comment.
Good call. I'll add username/password support (RFC 1929 sub-negotiation) to the SOCKS5 handshake. When credentials are set, the greeting advertises method 0x02 instead of 0x00, and Tor uses the unique credentials to isolate circuits. The Proxy API can accept optional credentials at construction or via a setter for rotation.
Add SOCKS5 proxy support (RFC 1928) alongside existing HTTP CONNECT. Uses domain-based addressing (ATYP 0x03) so DNS resolution happens at the proxy, enabling .onion routing through Tor. New public API: - Proxy::new_socks5(addr) for unauthenticated SOCKS5 - Proxy::new_socks5_with_credentials(addr, user, pass) for RFC 1929 username/password auth (enables Tor circuit isolation) Both sync and async handshake paths share protocol logic via helpers, with only I/O differing between them. Motivation: ldk-node needs to route HTTP calls (RGS, scoring) through Tor's SOCKS proxy. See lightningdevkit/ldk-node#834. Tests: 7 parsing tests + 8 mock handshake tests covering success, .onion domains, server rejection, port encoding, domain length validation, credential auth, credential rejection, and no-auth fallback.
FreeOnlineUser
force-pushed
the
socks5-proxy
branch
from
76d3875 to
fb5e7f3
Compare
|
Updated: added |
3 participants
Add SOCKS5 proxy support (RFC 1928) alongside existing HTTP CONNECT proxies.
Motivation
ldk-node needs to route HTTP calls (RGS, scoring, LNURL-auth) through Tor's SOCKS proxy when TorConfig is enabled. The existing
proxyfeature only supports HTTP CONNECT, which doesn't handle .onion addresses. See lightningdevkit/ldk-node#834.SOCKS5 and HTTP CONNECT serve different use cases:
Both coexist behind the existing
proxyfeature flag.Changes
Proxy::new_socks5(addr)constructor (public API)ProxyKind::Socks5variantproxy.is_socks5()before the existing HTTP CONNECT pathTests
10 new tests:
Notes