PROXY protocol support

[cperciva]

At some point, we may wish to add PROXY protocol support to spiped. I don't think there's any urgency to this, but I'm opening an issue so I don't forget about it.

[TimWolla]

In fact I already thought about suggesting / implementing this in the past. Here's some comments on how this feature should work in my opinion:

Sending the PROXY header should be supported for both an encrypting and decrypting spiped:

For the decrypting end you might want to know which the client is that connects using the secret (probably especially helpful in combination with spipe).
For the encrypting end you get the classic PROXY protocol support that sends the IP address of the client (probably less important, as you would not expose an encrypting spiped to the Internet in most cases).

IMO there is no need to add a parser for the proxy protocol as spiped does not log any information anyway. If a service in front of the encrypting spiped wants to use the proxy protocol those bytes are simply forwarded and thus correctly interpreted by the service behind the decrypting spiped.

TL;DR: Add a single -P option that sends a PROXY header into the outgoing pipe, regardless whether you're encrypting or decrypting should be enough.

[cperciva]

Agreed. The only slightly tricky bit is that the PROXY header needs to go into the plaintext stream -- when decrypting this means simply sending the data, but when encrypting this means encrypting it into a block and sending that. So the PROXY header data would need to be injected at two different points. :-(

[TimWolla]

Oh and what just comes to my mind, you might need some interpretation of proxy protocol, because the specification states that:

The sender must ensure that all the protocol header is sent at once.

Or does spiped already ensure that a single encrypted packet results in a single decrypted packet on the receiving side? Otherwise the PROXY header of an encrypting spiped might be split up by an decrypting spiped.

[cperciva]

It will be passed via a single syscall. What happens in the TCP stack after that point we have no control over; but nobody else using the PROXY protocol has control either, so we're no worse off than anyone else.

[testcaoy7]

Using 3proxy at server end as spiped target can easily do this.

[Vesnica]

I use script below to enable connect through http(s) proxy:

#!/bin/bash

#sudo apt-get install spiped proxytunnel
#dd if=/dev/urandom bs=256 count=1 of=keyfile

PIDFILE=spiped.pid
PORT=23128
REMOTE=10.10.10.10:$PORT
PROXY=proxy.com:80
LISTEN_PORT=8080

killall -w proxytunnel
nohup proxytunnel -a $PORT -p $PROXY -d $REMOTE &

if [ -f $PIDFILE ]; then
    pkill -F $PIDFILE
    rm -f $PIDFILE
fi
spiped -e -s "[0.0.0.0]:$LISTEN_PORT" -t "[127.0.0.1]:$PORT" -k keyfile -p $PIDFILE

[testcaoy7]

However, it will be amazing if spiped can have native proxy support.

[topmask]

I need to send the SPIPED encryption on the client, then SPIPED decryption to the 3proxy proxy to the website, then return the data to SPIPED encryption, and then SPIPED client decryption. How to deal with it?

[cperciva]

I need to send the SPIPED encryption on the client, then SPIPED decryption to the 3proxy proxy to the website, then return the data to SPIPED encryption, and then SPIPED client decryption. How to deal with it?

I have no idea what you're asking here, or what it has to do with this github issue.