[stunnel-users] Feature request: set environment variable for inetd-type program
roam at ringlet.net
Sat Jan 24 02:37:38 CET 2009
On Fri, Jan 23, 2009 at 07:34:00PM +0100, Michael Renner wrote:
> I am not a programmer, I am a writer and user, so I have to ask kindly for a
> additional stunnel feature
> I need the ability to push some information from the stunnel client side to
> the server side. To be more concrete: a self written script that is called by
> stunnels 'exec' statement need some settings, e.g. username and password. My
> idea is to configure this in the client side stunnel.conf and pass this as a
> environment variable to this script.
> There is no chance to pack these stings in a client certificate, because
> everybody who is able to handle snoop/tcpdump will be able to read this.
> I imagine a configuration like this:
> client stunnel.conf
> accept = 127.0.0.1:1234
> connect = 220.127.116.11:443
> env = "SUSER=renner"
> env = "SPASS=geheim"
> server stunnel.conf
> accept = 18.104.22.168:443
> exec = /opt/foo/script.sh
> env = yes
> My question to the developers: do you think this is a helpful feature, also
> for others?
IMHO, this would not be easy to do, since the only communication between
the stunnel client and server is through a standard SSL connection.
Neither the client nor the server is aware that the other side is also
an stunnel process, and they have pretty much no way to communicate
except for the standardized SSL/TLS handshake, authentication, and
Well, actually, there is the TLS Extensions mechanism, which would seem
to work exactly in the way you want: the client sends additional
information in the initial ClientHello message and if the server accepts
the extension, both parties are allowed to send additional records
(including records of new types) during the course of both the TLS
handshake and the TLS connection later on. However, as described in
RFC5246, the TLS extensions are centrally administered by IANA, and it
would be a lengthy and possibly difficult process to draft a new
extension proposal, pass it through whatever working groups are
necessary, have IANA approve it and add it to their list, and then deal
with any interoperability problems from different TLS implementations :)
Not impossible, mind, just difficult, and involving lots of other people
besides the stunnel developers :)
Other than TLS extensions, there is NO way that I know of for the
stunnel client to identify an stunnel server on the other side, let
alone pass any additional information to it :(
Peter Pentchev roam at ringlet.net roam at space.bg roam at FreeBSD.org
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
I am the meaning of this sentence.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
More information about the stunnel-users