Bucci, David G wrote:
Thanks, guys, good ideas. Wow, subst, that's a blast from the past.
Some
deployment sites will have networked homedirs, some won't, Michal.
Sure. That's exactly why I wrote "most" and not "all".
Can I confirm, if stunnel is run by the user (whether manually or as
part
of a login script), then when the user logs off, the process can be
relied
on to be killed? I'm concerned that a leftover tunnel could be used to masquerade by a subsequent logon-ee).
http://msdn.microsoft.com/en-us/library/aa376876%28VS.85%29.aspx
And ... does stunnel for Windows have any inherent way to only allow localhost access? (host.allow type mechanism). Our clients are not
running
firewalls on their PCs, at least not all of them (closed network situation). Or alternatively, any way to specify what user is allowed access (like iptables can do in Linux)? Sorry, I'm not a Windows guy,
I'm
still reeling from the fact that Windows doesn't have any inherent way
to
do transparent proxying (not even on the Server versions).
The same mechanism is used on Windows and Unix/Linux. You need to bind the service to the loopback interface instead of all interfaces, e.g.: accept=127.0.0.1:12345
As a feature request for the Windows version ... some way to tie in to
the
system keystore, so that user certificates that are populated there can
be
directly used. Implicit in that would be DER (and probably PKCS#12) support, I suppose.
I think this request should rather be addressed to the OpenSSL team. AFAIK Windows Certificate Store was specifically designed to prevent non-Microsoft SSL implementations from using it directly, i.e. without manual key export.
Best regards, Mike