On Fri, Jan 23, 2009 at 07:34:00PM +0100, Michael Renner wrote:
Moin,
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 [foo] accept = 127.0.0.1:1234 connect = 192.0.20.0:443 env = "SUSER=renner" env = "SPASS=geheim"
server stunnel.conf [foo] accept = 192.0.20.0: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 connection.
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 :(
G'luck, Peter