Feature request: set environment variable for inetd-type program
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? Greetings -- |Michael Renner E-mail: michael.renner@gmx.de | |D-81541 Munich Germany ICQ: #112280325 | |Germany Don't drink as root! ESC:wq
I'm not a developer on stunnel so my opinion doesn't carry much weight :-) But, to me, this seems a bit outside the scope of what's stunnel's main goal in life. Why not just have that authentication handled between the client and server programs using the tunnel stunnel provides? Or maybe I just don't quite get what you're trying to accomplish (a totally plausible option!). -Claus -----Original Message----- From: stunnel-users-bounces@mirt.net [mailto:stunnel-users-bounces@mirt.net] On Behalf Of Michael Renner Sent: Friday, January 23, 2009 1:34 PM To: stunnel-users@mirt.net Subject: [stunnel-users] Feature request: set environment variable for inetd-type program 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? Greetings -- |Michael Renner E-mail: michael.renner@gmx.de | |D-81541 Munich Germany ICQ: #112280325 | |Germany Don't drink as root! ESC:wq _______________________________________________ stunnel-users mailing list stunnel-users@mirt.net http://stunnel.mirt.net/mailman/listinfo/stunnel-users
On Friday 23 January 2009, Lund, Claus wrote:
I'm not a developer on stunnel so my opinion doesn't carry much weight :-) But, to me, this seems a bit outside the scope of what's stunnel's main goal in life. Why not just have that authentication handled between the client and server programs using the tunnel stunnel provides? Or maybe I just don't quite get what you're trying to accomplish (a totally plausible option!).
Moin, thanks for your answer. The scenario is simple; at least at the first view. To reach a proxy server in a country or an other network with less internet restrictions. This is more or less a simple setup. stunnel at both ends (firefox can not use https to connect to a proxy). challenge no 1: protect the proxy from use/abuse by others challenge no 2: nobody must know that you use a proxy, even if somebody is using a network sniffer to track the network packages. Therefore, this proxy must act like a harmless https webserver for others. scenario no 1: a curious person knows, that I have a lot of traffic to 192.0.20.1:443. He connect with a browser to https://192.0.20.1 and get a squid error message, that this request was not unserstood -> suspect scenario no 2: The curious person connect with a browser to https://192.0.20.1 and get a password dialog: suspect scenario no 3: The curious persion connect to https://192.0.20.1 and get a client certificate error -> suspect I have success to set an additional http header using the firefox plugin "modify header". as a door opener. At the moment, every connect with this header is processed as a request to the proxy and it should be possible to find a way to treat connections without this header like a normal http request (or a redirection to a harmless web site). But I am afraid to forget to switch off the header entry when I surf without the proxy between (because the proxy filter out this header and its value). Well, the possibility to set some variables for an inetd-type program (a simple script) will solve this problem in a simple way. If the right variable is set: forward the connection to the proxy, if not forward the connection to a web server. Maybe you have an other idea? CU
-Claus
-----Original Message----- From: stunnel-users-bounces@mirt.net [mailto:stunnel-users-bounces@mirt.net] On Behalf Of Michael Renner Sent: Friday, January 23, 2009 1:34 PM To: stunnel-users@mirt.net Subject: [stunnel-users] Feature request: set environment variable for inetd-type program
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?
Greetings
-- |Michael Renner E-mail: michael.renner@gmx.de | |D-81541 Munich Germany ICQ: #112280325 | |Germany Don't drink as root! ESC:wq
Hello, 2009/1/26 Michael Renner wrote -to me) :
I see the only chance in accepting every SSL connection, check somehow for a authentication inside the ssl channel and redirect the traffic to the proxy (if the authentication succeed) or to a webserver if the authentication failed.
If I understand well, the feature you want is : if authentifcation succeeds connect to good_server else connect to fake_server. The check for authentification is done in file verify.c. The functions return 1 if authentication succeeds and 0 if it fails. This features rely on openssl backend and are specified in http://www.openssl.org/docs/ssl/SSL_CTX_set_verify.html. IMHO, if you want to implement your feature, I think you can patch stunnel to: - in file verify.c * maintain your own error storage variable * make the verify functions always return 1 - in client.c, function init_remote, connect on selective host depending on your own error variable (good_server or fake_server). - in options.c : add the new option connect_fake option in services section. I'm a little too busy to implement this shortly. -- Christophe Nanteuil
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 -- Peter Pentchev roam@ringlet.net roam@space.bg roam@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.
participants (4)
-
Christophe Nanteuil -
Lund, Claus -
Michael Renner -
Peter Pentchev