- @aus's branch also includes PR for
custom headers, thanks @AkeemMcLennon (closes#90)
- support client connections via socks
- add more architectures to the built releases
- remove vendor (go.sum will enforce correct deps)
Although reverse port forwarding (sharing client ports with the server)
should not generally leak any resources from the server to the client,
the facility may nevertheless be abused if the client is able to open a
server port which is otherwise meant for some other purpose on the
server. (This might happen, for instance, if a service on the server has
crashed or becomes somehow disabled, thus freeing the port which would
otherwise be occupied by the service.)
To mitigate such potential abuse, disable reverse port forwarding by
default and introduce server option --reverse to enable it explicitly.
Additionally, subject reverse port forwarding remotes to server-side
--authfile restrictions (for instance, "^R:0.0.0.0:7000$").
Normal port forwarding shares server ports to the client, allowing the
client to access ports on the server (or ports on other machines
accessible from the server). Sometimes, however, it is necessary to
share ports in the opposite direction, allowing the server to access
ports on the client (or ports on other machines accessible from the
client). Reverse port forwarding is analogous to ssh's -R forwarding
which complements normal -L forwarding.
Reverse port forwarding remotes are specified as
"R:<local-interface>:<local-port>:<remote-host>:<remote-port>", where
<local-interface> and <local-port> refer to the server side, and
<remote-host> and <remote-port> refer to the client side. For instance,
"R:2222:localhost:22" forwards port 2222 on the server to port 22 on the
client.
An upcoming enhancement will add reverse port forwarding support (client
sharing its ports to the server) to complement the existing port
forwarding (server sharing its ports to the client). As a first step,
introduce notation for specifying a remote for reverse port forwarding;
i.e. "R:<local-interface>:<local-port>:<remote-host>:<remote-port>".
At this stage, reverse port forwarding remotes are recognized but never
actually created. A subsequent change will flesh out the functionality.
server/handleTCPStream() is sufficiently general to handle TCP stream
functionality for both the client and server. Therefore, move it to
share/ so it can be re-used by the client when chisel learns to
support reverse port forwarding, in which case TCP stream handling
will be done by the client rather than the server.
Aside from a minor dependency upon chserver.Server, the existing
Server.handleTCPStream() is sufficiently general for either the server
or client side. For instance, when chisel learns to support reverse
port forwarding, in which case the client, not the server, will be
handling the TCP stream, it will make sense to re-use existing
functionality rather than duplicating it. Therefore, divorce the TCP
stream handling code from chserver.Server, freeing it up for use by
the client too.
Presently, only the server maintains connection statistics, however,
when reverse port forwarding is eventually supported by chisel, the
client will also want to do so. Rather than duplicating this
functionality in the client, generalize the existing functionality as
chshare.ConnStats, allowing it to be used by both client and server.
Jaime Pillora