PageViews: 2,911 hits / 368 nets

DeleGate as a multiplexed SOCKS tunnel

Yutaka Sato
August 6, 2006

In the version 9.2.4, DeleGate as a SOCKS proxy supported an easy configuration for relaying SOCKS over SSL and multiplexing SOCKS connections over a single persistent connection using SockMux.

  ____________________                                    ____________________
                      \                                  /
                      |                                  |                     
   client --+ SOCKS   |              SOCKS               |      +---> server  
            +-----> DeleGate <=====================> DeleGate --+             
   client --+         |             SockMux              |      +---> server  
                      |               SSL                |                     
  ____________________/   (encrypted and multiplexed)    \____________________

(For you unfamiliar with DeleGate, HowToDG will be helpful to read the following examples, install and use DeleGate)

Relevant Parameters:

EXAMPLES

The simplest configuration of DeleGate as a SOCKS server (SOCKS-DeleGate):

hostA% delegated -P1080 SERVER=socks

Chaining two SOCKS-DeleGate:

hostA% delegated -P1080 SERVER=socks
hostB% delegated -P1080 SERVER=socks SOCKS=hostA:1080

Encrypting the communication between two SOCKS-DeleGate servers with SSL:

hostA% delegated -P1080 SERVER=socks STLS=fcl
hostB% delegated -P1080 SERVER=socks STLS=fsv SOCKS=hostA:1080

Multiplexing the communication between two SOCKS-DeleGate servers with SockMux:

hostA% delegated -P1080 SERVER=socks SOCKMUX=hostA:8000:acc
hostB% delegated -P1080 SERVER=socks SOCKMUX=hostA:8000:con SOCKS=hostA:1080

The SockMux connection can be in the reverse direction of the connection of SOCKS protocol as this:

hostA% delegated -P1080 SERVER=socks SOCKMUX=hostB:8000:con
hostB% delegated -P1080 SERVER=socks SOCKMUX=hostB:8000:acc SOCKS=hostA:1080

By default, the communication over SockMux is encrypted in the "Credhy" algorithm. It can be replaced with SSL with ",ssl" option as this:

hostA% delegated -P1080 SERVER=socks SOCKMUX=hostA:8000:acc,ssl
hostB% delegated -P1080 SERVER=socks SOCKMUX=hostA:8000:con,ssl SOCKS=hostA:1080



TODO:
There are several features not available yet but to be implemented in the future.

- Bidirectional SOCKS-DeleGate servers over SockMux:

hostA% delegated -P1080 SERVER=socks SOCKMUX=hostA:8000:acc SOCKS=hostB:1080
hostB% delegated -P1080 SERVER=socks SOCKMUX=hostA:8000:con SOCKS=hostA:1080

- Simplified configuration parameters:

hostA% delegated -P1080 SERVER=socks SOCKS=hostB:1080.sox
hostB% delegated -P1080 SERVER=socks SOCKS=hostA:1080.sox

- Connecting multiple SockMux clients to a single SockMux server
- Routing between SockMux clients (a SockMux server like a reflector)
- On-demand SockMux with a server like HTTP to multiplex connections

( excerpt from the reference manual )

DeleGate reference manual version 9.9 / Socks server
[CTX] [ALL] Socks server

Socks server

    Socks-DeleGate with SERVER=socks accepts both SocksV4 and SocksV5, whereas SERVER=socks4 and SERVER=socks5 accepts only SocksV4 and SocksV5 respectively. Currently, only USER/PASS authentication scheme of SocksV5 is supported.

    Example: Socks-DeleGate

      # delegated -P1080 SERVER=socks
    Example: forwarding to an upstream Socks server

    To accept an incoming TCP connection via a SOCKS-DeleGate server, the network interface to be used for it is selected automatically by DeleGate (based on the DST.ADDR or DSTIP which is sent from a SOCKS client as the parameter of the BIND command). With the SRCIF parameter, you can select a network interface (and port number) manually, with the pseudo protocol name "tcpbind". The complete syntax of the parameter is SRCIF= "[host]:[port]:tcpbind[:dstHostList[:srcHostList]]". Typically, only the host filed is specified to select a network interface, like SRCIF="150.29.202.120::tcpbind" for example.

    NOTE: When you chain DeleGate with another SOCKS server, it may cause problems in UDP relaying due to the private and tentative extensions to the SOCKS protocol by DeleGate. The following SRCIF parameters can be useful to escape such problems.

    • SRCIF="host:port:socks-udp-tosv" -- network interface to servers
      SRCIF="0.0.0.0:0:socks-udp-tosv" makes DeleGate as a SOCKS client behave compliantly to the SOCKSv5 specification on UDP ASSOCIATE.
    • SRCIF="host:port:socks-udp-tocl" -- network interface to clients
      SRCIF="0.0.0.0:0:socks-udp-tocl" suppresses the failure in DeleGate as a SOCKS server trying to bind a UDP socket to a specific port number.

DeleGate reference manual version 9.9 / multiplexed SOCKS/MASTER/PROXY over SockMux
[CTX] [ALL] multiplexed SOCKS/MASTER/PROXY over SockMux
SOCKMUX parameter*  ==  SOCKMUX=host:port:option[,option]*
            option  ==  acc | con | ssl
                    --  default: none
                    --  status: tentative
    If specified together with SOCKS, PROXY, MASTER (to chain two DeleGate), then the communication between DeleGate is multiplexed on a single persistent connection using SockMux. This is useful to reduce the delay to establish many connections repeatedly between DeleGate which are running distant from each other with long RTT.

    host:port specifies the port toward which a SockMux persistent connection is established. The connection is established from the DeleGate with "con" option to the DeleGate with "acc" option.

    Options:

      acc -- accept a SockMux connection at "host:port".
      con -- connect a SockMux connection to "host:port".
      ssl -- use SSL instead of the "Credhy" encryption.

    Example: SOCKS proxies chained over SockMux

    Example: SOCKS proxies chained over SockMux connected from the server side

    Example: HTTP proxies chained over SockMux

    Example: HTTP via SOCKS proxy chained over SockMux


DeleGate reference manual version 9.9 / SockMux server
[CTX] [ALL] SockMux server

SockMux server

    SockMux is an experimental protocol designed for inter-DeleGate communication. It is a simple protocol for "port forwarding" to accept, relay and destroy connections, multiplexed over a single persistent connection. A pair of SockMux-DeleGate establish and retain a connection between them, then forward port from local to remote each other over the connection.

    The persistent connection is established with "-Phost:port" parameter at receptor side, and "SERVER=sockmux://host:port" at connector side. The port to accept outgoing connections to be forwarded to remote is specified with PORT="listOfPorts parameter. The server to be connected for incoming connections from remote is specified with a postfix string ",-in" like SERVER="telnet://host:23,-in".

    An incoming connection can be processed with DeleGate as a proxy of the specified protocol. If only protocol name is specified like SERVER="telnet,-in", or if "-in" is postfixed like "-in(option list)", then a DeleGate is invoked to process the connection. The option list is passed to the invoked DeleGate as the list of command line options. For example, SERVER="telnet://host,-in(+=config.cnf)" will invoke a DeleGate with command line options like ``delegated SERVER=telnet://host +=config.cnf''.

    Example: bi-directional SockMux-DeleGate

      hostX% delegated SERVER=sockmux -PhostX:9000 PORT=9023 SERVER="telnet://hostX,-in"
      hostY% delegated SERVER=sockmux://hostX:9000 PORT=9023 SERVER="telnet://hostY,-in"
      // a pair of SockMux-DeleGate is connected at the port "hostX:9000", then
      // the port "hostX:9023" is forwarded to "telnet://hostY"
      // the port "hostY:9023" is forwarded to "telnet://hostX"

    Example: uni-directional SockMux-DeleGate

      hostX% delegated SERVER=sockmux -PhostX:9000 SERVER="telnet://hostX,-in"
      hostY% delegated SERVER=sockmux://hostX:9000 PORT=hostY:9023
      // hostY:9023 is forwarded to "telnet://hostX".

    Example: uni-directional to proxy-Telent-DeleGate

      hostX% delegated SERVER=sockmux -PhostX:9000 PORT=hostX:9023
      hostY% delegated SERVER=sockmux://hostX:9000 SERVER="telnet,-in"
      // hostX:9023 is forwarded to a Telnet proxy on hostY.

    When SockMux is used just to relay data between sockets, without interpreting the application protocol relayed over SockMux, such relaying can be represented with simpler expression using DEST parameter instead of SERVER as follows:

      DEST=host:port[:srcHostList] for SERVER=tcprelay://host:port,-in[:-:srcHostList]
      DEST=host:port/udp[:srcHostList] for SERVER=udprelay://host:port,-in[:-:srcHostList]

    Example: tcprelay over SockMux

      hostX% delegated SERVER=sockmux://hostY:9000 PORT=hostX:111
      hostY% delegated SERVER=sockmux -PhostY:9000 DEST=hostT:111
      // hostX:111/tcp is forwarded to the server at hostT:111/tcp via hostY.

    Example: relaying UDP over SockMux/TCP

      hostX% delegated SERVER=sockmux://hostY:9000 PORT=hostX:53/udp
      hostY% delegated SERVER=sockmux -PhostY:9000 DEST=hostU:53/udp
      // hostX:53/udp is forwarded to the server at hostU:53/udp via hostY.

    Another way to establish a persistent connection between two SockMux-DeleGate is using a FIFO device like named pipe. It is specified like SERVER=sockmux:commtype@fifoName where commtype is one of "commin", "commout", and "comm", which represents uni-directional input, uni-directional output and bi-directional input/output respectively.

    Example: use fifo device on a host

      % mkfifo /tmp/com0
      % mkfifo /tmp/com1
      serv1) SERVER=sockmux:commin@/tmp/com0 SERVER=sockmux:commout@/tmp/com1 ...
      serv2) SERVER=sockmux:commin@/tmp/com1 SERVER=sockmux:commout@/tmp/com0 ...

    Example: use communication port between two hosts (not tested yet)

      host1) SERVER=sockmux:comm@com1 ...
      host2) SERVER=sockmux:comm@com2 ...

    The persistent connection can be established by a given external program invoked by DeleGate. The process of the program is passed a socket to/from DeleGate at file descriptor number 0 and 1;

    Example: establish connection by external command

      % SERVER="sockmux:proc@connectCommand" ...

    The destination SERVER for an incoming connection from remote can be selected depending on which port it was accepted. A SERVER parameter postfixed with ":-:-Pxxxx" will be applied only to connections which is accepted on remote host with PORT=xxxx.

    Example: forwarding multiple port

      hostX% ... PORT=8023,8080
      hostY% ... SERVER=telnet,-in:-:-P8023 SERVER=http,-in:-:-P8080
      // hostX:8023 is forwarded to Telnet-proxy on hostY
      // hostX:8080 is forwarded to HTTP-proxy on hostY

    NOTE: forwarding FTP data connection is not supported (yet).


DeleGate reference manual version 9.9 / <A Href=/delegate/Manual.htm?TLS id=hgen>TLS</A> negotiation control
[CTX] [ALL] TLS negotiation control
STLS parameter*     ==  STLS=stlsSpecs[,sslwayCom][:connMap]
         stlsSpecs  ==  [-]stlsSpec[/im][/ssl][,stlsSpecs]
          stlsSpec  ==  fsv | fcl | mitm | imimSec
         sslwayCom  ==  {sslway [-Vrfy] [-CApath dir] ...}
           connMap  ==  ProtoList:dstHostList:srcHostList
                    --  default: none
                    --  restriction: applicable to HTTP, FTP, SMTP, POP, IMAP, SOCKS
                    --  required: SSLway
    This parameter controls the initiation of SSL (TLS) based on a negotiation between client and server in each application protocol. The common scheme of the negotiation is known as "STARTTLS". "fsv" specifies using SSL with server and "fcl" specifies using SSL with client. When SSL is not supported on a connection, the STARTTLS negotiation will fail and the connection will be closed by default. To continue a session even when SSL is not available, prefix "-" to "fsv" or "fcl".

    If "fcl" is specified, a client may start SSL without STARTTLS negotiation. Such implicit SSL negotiation from the client-side is detected by peeping a SSL hand-shake packet on the connection from the client-side at the beginning of a session for a certain period specified with imimSec. The default value is "im0.25" (250m seconds). "-im" disables this implicit SSL negotiation. If a stlsSpec is followed with "/im" as STLS="fsv/im" for example, SSL with the peer (with the server in this case) is applied without the STARTTLS negotiation.

    If "mitm" is specified, it behaves like "-fcl,-fsv" that is if SSL is enabled in the client side then SSL on the server side is enabled. It can be used with a HTTP proxy DeleGate as a "secure proxy" or "SSL-tunnel" to peep the bidirectional communication in CONNECT method, relaying it as a usual HTTP applying filters and cache. ("mitm" means "Man-In-The-Middle" mode) If it is set optional as "STLS=-mitm" then the MITM mode is activated only when the client specified the server name prefixing with "-mitm." as "https://-mitm.host.domain/" for "https://host.domain/".

    If non default SSLway command path or options are necessary to be used, the SSLway command can be specified after stlsSpecs as STLS="fcl,sslway -Vrfy -cert mycert.pem" for example.

    Example:

      STLS="fcl" -- use SSL with client (exit the session if not available)
      STLS="-fcl" -- use SSL with client if available
      STLS="fsv,-fcl" -- use SSL with server, and with client if available
      STLS="fsv/ssl" SERVER="ftp" -- use AUTH SSL instead of AUTH TLS
      STLS="fsv,im0.5" SERVER="ftp" -- automatic detection of implicit/explicit SSL server