Thx for replying, Scott ... how did you handle multiple users on the PC, though? They all shared that cert?
I thought about having a single location and copying to there on user login (from a standard location in a user's home dir, e.g.) ... then firing up stunnel ... but it seems like so much can go wrong, resulting in User B accessing using User A's certificate (because the copy failed, e.g.). And we're leery of exposing User A's cert to User B - especially since stunnel doesn't support encryption of the user's key, right? So the permissions would be a little tricky and maybe fragile.
Seems like there should be a straightforward way to do it, dadnabit!
________________________________ From: Scott Gifford [email protected] To: Bucci, David G Cc: [email protected] [email protected] Sent: Mon Aug 30 17:41:09 2010 Subject: EXTERNAL: Re: [stunnel-users] Individual user certs for each person who uses Windows PC
On Mon, Aug 30, 2010 at 3:41 PM, Bucci, David G <[email protected]mailto:[email protected]> wrote: [ ... ] I've tried using envvars in the stunnel.conf (e.g., cert = %USERPROFILE%\usercert.pem), tried adjusting the command line to include "-p %USERPROFILE%\usercert.pem" as an option ...
We implemented something similar by simply making a "C:\stunnel" directory on each PC, naming the certificate the same thing on all machines, then hardcoding that path into the stunnel configuration (e.g. "C:\stunnel\usercert.pem"). Not quite as nice as %USERPROFILE%\usercert.pem, but it worked. :-)
Hope this is helpful,
----Scott.
On Mon, Aug 30, 2010 at 6:54 PM, Bucci, David G [email protected]wrote:
Thx for replying, Scott ... how did you handle multiple users on the PC, though? They all shared that cert?
No, they were single-user PCs so it was somewhat simpler.
stunnel itself is small and IIRC it looks in the directory where it's located for its configuration file and certificates, so maybe you could give each user their own copy of stunnel in a subdirectory of %USERPROFILE% and use relative paths for everything? Or use a bit of VBScript to generate the configuration file before starting stunnel.
Maybe there is a more elegant approach, I'm just throwing ideas out there. :)
Hope this helps,
-----Scott.
Hello, I suggest you have a look at the windows "subst" command (available in ALL versions of windows), that allows a virtual drive to be mapped to a directory. So you can imagine that stunnel always uses the cert Z:/acert.pem but with the Z drive pointing to C:\users\userA, or to ...userB..., with a simple startup bat script. If the script fails, then NO risk that userB uses cert of user A. But in that case stunnel must be started ALSO in the startup menu script (the same as that doing the "subst"), and NOT as a service.
Hope this may help, Pierre
Le 31/08/2010 00:54, Bucci, David G a écrit :
Thx for replying, Scott ... how did you handle multiple users on the PC, though? They all shared that cert?
I thought about having a single location and copying to there on user login (from a standard location in a user's home dir, e.g.) ... then firing up stunnel ... but it seems like so much can go wrong, resulting in User B accessing using User A's certificate (because the copy failed, e.g.). And we're leery of exposing User A's cert to User B - especially since stunnel doesn't support encryption of the user's key, right? So the permissions would be a little tricky and maybe fragile.
Seems like there should be a straightforward way to do it, dadnabit!
*From*: Scott Gifford [email protected] *To*: Bucci, David G *Cc*: [email protected] [email protected] *Sent*: Mon Aug 30 17:41:09 2010 *Subject*: EXTERNAL: Re: [stunnel-users] Individual user certs for each person who uses Windows PC
On Mon, Aug 30, 2010 at 3:41 PM, Bucci, David G <[email protected] mailto:[email protected]> wrote: [ ... ]
I've tried using envvars in the stunnel.conf (e.g., cert = %USERPROFILE%\usercert.pem), tried adjusting the command line to include "-p %USERPROFILE%\usercert.pem" as an option ...We implemented something similar by simply making a "C:\stunnel" directory on each PC, naming the certificate the same thing on all machines, then hardcoding that path into the stunnel configuration (e.g. "C:\stunnel\usercert.pem"). Not quite as nice as %USERPROFILE%\usercert.pem, but it worked. :-)
Hope this is helpful,
----Scott.
stunnel-users mailing list [email protected] http://stunnel.mirt.net/mailman/listinfo/stunnel-users
Pierre DELAAGE wrote:
Hello, I suggest you have a look at the windows "subst" command (available in ALL versions of windows), that allows a virtual drive to be mapped to a directory.
AFAIK most multi-user deployments map home directories from a file server. Stunnel could simply use a certificate from the mapped drive.
If the script fails, then NO risk that userB uses cert of user A. But in that case stunnel must be started ALSO in the startup menu script
(the same as that doing the "subst"), and NOT as a service.
Sure. There's also no way to know in advance (at boot time) which user is going to log in. 8-)
Mike
Thanks, guys, good ideas. Wow, subst, that's a blast from the past. Some deployment sites will have networked homedirs, some won't, Michal.
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).
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).
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.
Thx!
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Michal Trojnara Sent: Tuesday, August 31, 2010 7:18 AM To: [email protected] Subject: EXTERNAL: Re: [stunnel-users] Individual user certs for each person who uses Windows PC
Pierre DELAAGE wrote:
Hello, I suggest you have a look at the windows "subst" command (available in ALL versions of windows), that allows a virtual drive to be mapped to a directory.
AFAIK most multi-user deployments map home directories from a file server. Stunnel could simply use a certificate from the mapped drive.
If the script fails, then NO risk that userB uses cert of user A. But in that case stunnel must be started ALSO in the startup menu script
(the same as that doing the "subst"), and NOT as a service.
Sure. There's also no way to know in advance (at boot time) which user is going to log in. 8-)
Mike _______________________________________________ stunnel-users mailing list [email protected] http://stunnel.mirt.net/mailman/listinfo/stunnel-users
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
On 09/01/2010 09:02 PM, Michal Trojnara wrote:
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.
Hi Mike
You should look again - lots of non-M$ products use this API. e.g openvpn for Windows allows you to use the personal cert that other M$ components like MSIE uses - see " cryptoapicert"
--cryptoapicert select-string Load the certificate and private key from the Windows Certifi- cate System Store (Windows Only).
Use this option instead of --cert and --key.
This makes it possible to use any smart card, supported by Win- dows, but also any kind of certificate, residing in the Cert Store, where you have access to the private key. This option has been tested with a couple of different smart cards (GemSAFE, Cryptoflex, and Swedish Post Office eID) on the client side, and also an imported PKCS12 software certificate on the server side.
On 09/01/2010 09:02 PM, Michal Trojnara wrote:
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.
Hi Mike
You should look again - lots of non-M$ products use this API. e.g openvpn for Windows allows you to use the personal cert that other M$ components like MSIE uses - see " cryptoapicert"
--cryptoapicert select-string Load the certificate and private key from the Windows Certifi- cate System Store (Windows Only).
Use this option instead of --cert and --key.
This makes it possible to use any smart card, supported by Win- dows, but also any kind of certificate, residing in the Cert Store, where you have access to the private key. This option has been tested with a couple of different smart cards (GemSAFE, Cryptoflex, and Swedish Post Office eID) on the client side, and also an imported PKCS12 software certificate on the server side.
Hi, Other software using certs still have their own way to store and access them: eg firefox and opera browsers. Even Mozilla Thunderbird and Firefox store SEPARATELY their certs (!). I agree that things could be better but it is the way it is.
If M$ cryptoapi was a standard, maybe stunnel could use it to load certs and pass them to openssl, or -preferrably- specify a particular syntax to tell openssl to load them in that "standard manner". But it would add a huge amount of code for that, either in stunnel or openssl.
The same effect can be easily obtained by using M$ IE to export useful certs in a USER owned folder, to cer64 (ie pem) format, and then use these files in stunnel as usual. Every ordinary user can do that with a simple instruction.
"Subst" does in local the same job as "net use" on the network : mapping location (local for subst, remote for netuse) to a drive, so that -almost- the same startup script can be use to map drives and start stunnel, all this in a user context, not polluting other user context. Of course a script can use subst with something like this : subst z: %HOMEPATH% so that there is no need for a specific script per user.
Pierre
Le 06/09/2010 05:35, Jason Haar a écrit :
On 09/01/2010 09:02 PM, Michal Trojnara wrote:
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.
Hi Mike
You should look again - lots of non-M$ products use this API. e.g openvpn for Windows allows you to use the personal cert that other M$ components like MSIE uses - see " cryptoapicert"
--cryptoapicert select-string Load the certificate and private key from the Windows Certifi- cate System Store (Windows Only).
Use this option instead of --cert and --key. This makes it possible to use any smart card, supportedby Win- dows, but also any kind of certificate, residing in the Cert Store, where you have access to the private key. This option has been tested with a couple of different smart cards (GemSAFE, Cryptoflex, and Swedish Post Office eID) on the client side, and also an imported PKCS12 software certificate on the server side.
Jason Haar wrote:
You should look again - lots of non-M$ products use this API. e.g openvpn for Windows allows you to use the personal cert that other M$ components like MSIE uses - see " cryptoapicert"
--cryptoapicert select-string
You're right. OpenVPN includes cryptoapi.c code to use Windows Certificate Store. The code is released under 3-clause New BSD License and it should be fairly trivial to use it with stunnel. I've started coding the changes already. 8-)
Mike
I wrote:
You're right. OpenVPN includes cryptoapi.c code to use Windows Certificate Store.
It looks like it's more complex than just using OpenVPN code. Peter Runestig has only implemented 1 of 4 functions required for stunnel.
You may try: ftp://stunnel.mirt.net/stunnel/stunnel-4.34b7-tar.gz ftp://stunnel.mirt.net/stunnel/stunnel-4.34b7-installer.exe It implements new "cryptoapicert" service-level option that calls SSL_CTX_use_CryptoAPI_certificate() from openvpn-2.1.3.
I also discovered that Peter Runestig (original author of the cryptoapi.c code) is unfortunately dead for over 5 years, so he won't help us. 8-(
Mike
I wrote:
It looks like it's more complex than just using OpenVPN code.
I just found that native CryptoAPI code was added to OpenSSL 0.9.8i in 2008 by Steve Henson. OpenSSL could use some better documentation. 8-)
Now I'm looking for a way to use this new code (a.k.a. "capi" engine) in stunnel.
Mike
-
Bucci, David G -
Jason Haar -
Michal Trojnara -
Pierre DELAAGE -
Scott Gifford