stunnel doing exec; how to get remote IP address?

When inetd acts as a wrapper for a program it launches, the program can use
getpeername on stdin to determine the IP address that is connecting. I
wrote a program that uses this method to determine the remote IP... works.

I'm using stunnel to provide the same kind of function as the inetd wrapper
(interface an SSL connection to a program) using stunnel's exec= option. So
stunnel is directly invoking a program, whose stdin and stdout are then
tied to the socket.

But when my program does getpeername through stunnel's invocation, the IP
address returned in the local one and not the remote peer's IP. Does anyone
else know how I can find out this remote IP address?

--
Jem Berkes
http://www.sysdesign.ca/

Jem Berkes <(E-Mail Removed)> wrote:
> When inetd acts as a wrapper for a program it launches, the program can use
> getpeername on stdin to determine the IP address that is connecting. I
> wrote a program that uses this method to determine the remote IP... works.
>
> I'm using stunnel to provide the same kind of function as the inetd wrapper
> (interface an SSL connection to a program) using stunnel's exec= option. So
> stunnel is directly invoking a program, whose stdin and stdout are then
> tied to the socket.
>
> But when my program does getpeername through stunnel's invocation, the IP
> address returned in the local one and not the remote peer's IP. Does anyone
> else know how I can find out this remote IP address?

That's because inetd use dup2(2) to make the stdin descriptor the network
socket descriptor. In effect, the program exec'd by inetd behaves as if it
created, bound and listend on the network socket itself. However, stunnel
actually needs to read and write from the network socket (unlike inetd) in
order to encrypt and decrypt, and so it cannot simply pass the program that
network socket descriptor.

The only solution that I am aware of is to run stunnel as a daemon; stunnel
can run similarly to inetd. Instead of client->inetd->stunnel->server you
would have client->stunnel->server. stunnel _should_ then behave like inetd
in dupping the socket descriptor, but don't hold me to that.

Also, maybe stunnel has config options to pass the client IP on the command
line.

- Bill

> That's because inetd use dup2(2) to make the stdin descriptor the
> network socket descriptor. In effect, the program exec'd by inetd
> behaves as if it created, bound and listend on the network socket
> itself. However, stunnel actually needs to read and write from the
> network socket (unlike inetd) in order to encrypt and decrypt, and so
> it cannot simply pass the program that network socket descriptor.
>
> The only solution that I am aware of is to run stunnel as a daemon;

Actually, I am already doing that...

> stunnel can run similarly to inetd. Instead of
> client->inetd->stunnel->server you would have client->stunnel->server.
> stunnel _should_ then behave like inetd in dupping the socket
> descriptor, but don't hold me to that.

This is what I thought too; I have stunnel running as a daemon, so indeed
client->stunnel->server ... which seems to me very similar to inetd, so it
should be possible to get the client IP out on the server side.

> Also, maybe stunnel has config options to pass the client IP on the
> command line.

You're right, there was an option! I just discovered it now from their web
site, which has more information than the man pages. When invoking a
program using exec= (or -l, or -L) stunnel sets the environment variable
REMOTE_HOST to the remote IP address. This solves my problem!

--
Jem Berkes
http://www.sysdesign.ca/

in comp.unix.programmer i read:
>Jem Berkes <(E-Mail Removed)> wrote:

[re: using stunnel]

>> when my program does getpeername through stunnel's invocation, the IP
>> address returned in the local one and not the remote peer's IP. Does
>> anyone else know how I can find out this remote IP address?

>stunnel _should_ then behave like inetd
[if it is run as a daemon]
>in dupping the socket descriptor, but don't hold me to that.

not possible, stunnel has to remain in the loop, so to speak, and prevent
the client from direct socket access because of the ssl en/de-cryption
taking place.

>Also, maybe stunnel has config options to pass the client IP on the command
>line.

some o/s' (e.g., linux) have special mechanisms whereby stunnel can be used
as a transparent proxy; the kernel takes care of inserting the program into
the stream so provides what appears to the client as a direct connection.

--
a signature

those who know me have no need of my name <not-a-real-(E-Mail Removed)> wrote:
> in comp.unix.programmer i read:
> >Jem Berkes <(E-Mail Removed)> wrote:
>
> [re: using stunnel]
>
> >> when my program does getpeername through stunnel's invocation, the IP
> >> address returned in the local one and not the remote peer's IP. Does
> >> anyone else know how I can find out this remote IP address?
>
> >stunnel _should_ then behave like inetd
> [if it is run as a daemon]
> >in dupping the socket descriptor, but don't hold me to that.
>
> not possible, stunnel has to remain in the loop, so to speak, and prevent
> the client from direct socket access because of the ssl en/de-cryption
> taking place.
>

d'oh!

> >Also, maybe stunnel has config options to pass the client IP on the command
> >line.

> some o/s' (e.g., linux) have special mechanisms whereby stunnel can be used
> as a transparent proxy; the kernel takes care of inserting the program into
> the stream so provides what appears to the client as a direct connection.

I noticed the -T option in stunnel. How is this implemented? Streams?

- Bill

in comp.unix.programmer i read:
>those who know me have no need of my name <not-a-real-(E-Mail Removed)> wrote:

>> some o/s' (e.g., linux) have special mechanisms whereby stunnel can be used
>> as a transparent proxy; the kernel takes care of inserting the program into
>> the stream so provides what appears to the client as a direct connection.
>
>I noticed the -T option in stunnel. How is this implemented? Streams?

linux doesn't have (tli) streams. systems that have them should be able to
push a handler which can provide that service. systems without it usually
have some sort of trickery inside the tcp stack to decide when header
fiddling or multiple interconnected fd's are needed (and safe).

--
a signature