xingplus / tunnelblick

Automatically exported from code.google.com/p/tunnelblick
0 stars 0 forks source link

ENHANCEMENT: Optional - Require Password to initiate tunnel #105

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
We had been maintaining an in-house GUI wrapper for OpenVPN since at least 
Panther.  With the 
Snow Leopard upgrade, rather than once again going over things and tuning it, I 
thought we 
would look at using and perhaps contributing to Tunnelblick.

One feature we use, though, is a requirement that the user (just any user, 
doesn't need to be 
admin) has to input their password in order to initiate the tunnel connection.  
This is largely to 
prevent someone from casually firing up the tunnel while temporarily using one 
of our VPN-
enabled laptops for casual web surfing/etc...  I realize that this is only a 
light and superficial 
layer of security and is of no use if the machine and keys were compromised.

We use local authentication against their login password via Apple's API's for 
this, so that it is 
always current and we do not have to try to keep the password on the key file 
up to date with 
their account password (not that we'd want them the same anyway).  Also, we do 
not allow this to 
be stored in the keychain, it is a required entry every time the tunnel is 
initiated.

When the tunnel drops, it would also re-prompt for a password to initiate the 
connection again, 
it would not continue to auto-reconnect in the background.

Is there any interest in such an optional feature in Tunnelblick?

Original issue reported on code.google.com by steve.p...@gmail.com on 2 Sep 2009 at 2:53

GoogleCodeExporter commented 9 years ago
I didn't see to change this as not being a defect or to make priority low.

Original comment by steve.p...@gmail.com on 2 Sep 2009 at 5:01

GoogleCodeExporter commented 9 years ago
I can't speak for Angelo, but I would guess that this would be of such limited 
usefulness, especially without 
some kind of per-login-id permission to use Tunnelblick, that he wouldn't want 
to add it. But I could be 
wrong and it could be done with a preference controlling whether or not it is 
done, defaulting to not doing it.

Even if it isn't added to Tunnelblick, you could make and deploy a customized 
version of Tunnelblick that 
includes any functionality you want. You could either change the code to do the 
authentication or change the 
up script to do it. That's the beauty of open source!

I've changed this to be an "Enhancement", with "Low" priority, as you suggested.

Original comment by jkbull...@gmail.com on 3 Sep 2009 at 10:16

GoogleCodeExporter commented 9 years ago
Decided we won't do this because it is such a specialized feature.

Original comment by jkbull...@gmail.com on 10 Sep 2010 at 3:10

GoogleCodeExporter commented 9 years ago
In looking this response over before posting it, I realized that you could also 
do what you want if you call a special program (or script) from a customized 
"up" script -- which would be called before the connection is made initially 
and at each reconnect. I think the "up" script can control whether or not the 
connection is made by returning a zero or non-zero result. Customized "up" 
scripts are easy, and could be included in a "Deployed" version of Tunnelblick. 
"There's more than one way to skin a cat."

Here was my original response:

The new "added programs" introduced in r1060 should enable you to do most of 
what you want.

Create a shell script or other program that determines whether the user should 
connect or not (returning a status of zero if the user is allowed to connect). 
Name this program "login_test.runOnConnect.wait.executable", and put it in a 
folder named "Menu" inside a folder named "Deploy". Then put the "Deploy" 
folder inside of "Tunnelblick.app/Contents/Resources".

The program will be run each time a connection is attempted (either "when 
Tunnelblick launches" or when the user clicks "Connect"). If it returns a zero, 
the connection will be attempted. If it returns a non-zero result, the 
connection will be abandoned without any indication to the user other than a 
message in the Console log.

Note that no attempt is made to stop reconnections by OpenVPN.

For more details, see
http://code.google.com/p/tunnelblick/wiki/wCusDeployed#Additional_Menu_Commands_
and_Programs

Original comment by jkbull...@gmail.com on 7 Oct 2010 at 10:56