RFC: Add HTTP CONNECT protocol support to dynamic forwarding (-D)

[hsq]

I agree that implementing a general HTTP parser/proxy inside
the dynamic forwarding code would not be desirable.

My thought was that the HTTP side does not need to be a full
HTTP proxy implementation. It could be limited to the minimal
CONNECT request handling needed to extract the target host and
port, and then hand off to the existing direct-tcpip path.

The main idea is separating protocol parsing from the forwarding
logic, for example:

    listener
       |
       +-- SOCKS adapter
       |
       +-- HTTP CONNECT adapter (minimal CONNECT support)
       |
       v
    target host:port
       |
       v
    existing direct-tcpip channel code

That said, I understand the preference for keeping ssh -D
SOCKS-only and handling this through an external shim.

At 2026-09-23 20:34:54, "Damien Miller" <djm at mindrot.org> wrote:
>On Wed, 23 Sep 2026, hsq wrote:
>
>> Hello OpenSSH developers,
>> 
>> I would like to discuss a possible enhancement for ssh dynamic
>> forwarding (-D).
>> 
>> Currently, dynamic forwarding provides a SOCKS proxy interface.
>> Applications connecting to the local forwarding port must speak
>> SOCKS4/SOCKS5.
>> 
>> The proposal is to allow the dynamic forwarding listener to also
>> accept HTTP CONNECT proxy requests, with automatic protocol detection.
>
>I'd rather not do this - the dynamic forwarding state machine is
>complicated enough and adding parsing for a textual protocol would
>just make it worse.
>
>IMO a better approach is to write a CONNECT->SOCKS shim that can
>accept HTTP CONNECT requests and translate them to SOCKS requests.
>
>Please try https://github.com/djmdjm/connect-to-socks as a basic
>example.
>
>-d
>_______________________________________________
>openssh-unix-dev mailing list
>openssh-unix-dev at mindrot.org
>https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev