FeatReq: Allow empty username/password when user-auth-pass configured

[Petiepooo]

There's a situation I've run into that I'd love to see a small improvement on.  It takes a little to describe, so please be patient and ask for clarification if I'm unclear...

I'm using DuoSecurity for two-factor auth with OpenVPN/TunnelBlick.  Following the guidelines at https://www.duosecurity.com/docs/openvpn I have added the plugin line to the server config.  Initially, I also added auth-user-pass to the client config, which pulls up a prompt for the username and password to be sent to the server (and auth-nocache and reneg-sec 0 to the client).  The username is always ignored by the server's plugin, as it uses the certificate's common name (CN) instead.

The password can be either "sms", "push", a TOTP presented by the companion phone app, or a HOTP received via sms.  The password could also be an empty string, which defaults to the method set via the web-based admin panel for the user (eg. "push" in my case).  At least that's what I believe, as I'm unable to send an empty string via TunnelBlick as long as auth-user-pass is in the client config..

I am currently using an alternate config where I add auth-user-pass-optional to the server config and remove auth-user-pass in the client config.  The server still does not use the username, and being that the client doesn't send a password (or perhaps does, but sends an empty string?), it uses my default method of "push", as described at the bottom of the FAQ at https://duo.com/docs/openvpn-faq.

I'd like to still use auth-user-pass in the client config, as that would allow me to enter a OTP if push isn't working.  However, it's annoying to have to enter a dummy entry in the username and "push" in the password when I'm not using a OTP, as that's the way I use it most of the time.  The problem is, if I don't put something in both of those fields, I get an error dialog from Tunnelblick saying they are required.  If I save them to my keyring, I don't get the option to enter something else before it connects.  It would be nice if TunnelBlick could be configured to:

1) allow empty passwords (accept and send an empty string),

2) allow empty usernames, or perhaps not even prompt for a username at all, and

3) optionally not allow saving credentials to the keychain (grey out or remove the checkbox) since OTPs shouldn't be reused.

If I were presented with just an optional password field with these changes implemented, I could simply hit enter to use the default method, enter another method such as "sms", or enter an OTP for alternate authentication.  Also, since the password is a OTP, saving to the keychain doesn't make sense, so having that option presented is just clutter.  Same with the username if the server just ignores it anyway in favor of the CN.

What do you think of those changes?  Do you think they would help make at least some multi-factor auth plugins easier to manage?

On a side note, I'm trying to understand the use of VPN Credentials under Advanced Settings of a configuration's details.  Admittedly, I don't plan on storing my credentials in a keychain, primarily because I'm using OTPs that are never the same.  I'm also the only user of my macbook.  Is there a good howto or faq that describes how named credentials are used and when named vs. common credentials would be appropriate?

Thanks!

--

Pete

[jkbull...gmail.com]

Thanks for your well-thought out comments and questions. My to-do list includes a rewrite of the username/password dialog box, so your post was timely.

I could certainly allow empty usernames and passwords; that's something that Tunnelblick does because in most cases you need both. I'll have to think about the implications (things like: should a user be able to "save" and empty username and/or an empty password?) but my initial reaction is to allow it; you make a reasonable argument that it is useful in at least some situations. So all you would do is hit enter, or type into the password field and click enter.

As to asking only for a password, it is tricky and may be in flux. OpenVPN asks for only one item at a time, but instead of Tunnelblick asking the user for them separately, Tunnelblick asks for both because OpenVPN always asks for both. However, there have been some changes recently proposed (I'm not sure they were accepted) that would allow the username and password to be held in a file (previously that ability had to be enabled at the time OpenVPN was built because it is such a security risk; they decided that since most Linux distributions did that, they would just enable it by default). There were also some changes proposed (again, I don't know if they were accepted) having to do with the changeover to use systemd, that had to do with username/passwords. Among the things that were proposed were to allow specification of a username but not a password, and that **might** mean that OpenVPN would no longer ask for both. (This would only show up in the git-master version of OpenVPN that Tunnelblick 3.6beta versions include.)

As to greying out the "Save" checkboxes, I'll have to think about that, too, but if my memory of the way they work is correct, I don't think anything needs changing. I'll look into that.

----------------

There isn't any documentation I'm aware of on the "VPN Credentials" tab other than the built-in help (little round "?" button on that tab). But the idea is to allow a set of configurations to share the same credentials (by giving that set of credentials a name and having each configuration say it is using the credentials with that name). I don't see that as being useful unless you are saving either or both of the username and password.

[jkbull...gmail.com]

I've looked into this, and there is a problem with OpenVPN's handling of empty usernames.

I created a test version of Tunnelblick that allows empty usernames and/or passwords. If Tunnelblick sends OpeNVPN an empty username, OpenVPN seems to ignore it -- it doesn't send the empty username on to the server and tell Tunnelblick it has done that, and it doesn't tell Tunnelblick that there is any problem or ask Tunnelblick for the username again. (An empty password is OK and works as expected.)

Usually after Tunnelblick provides the username and password to OpenVPN (via the management interface), OpenVPN sends them to the server and sends Tunnelblick a "WAIT" status message (which Tunnelblick displays as "Waiting for server response"). However, if Tunnelblick provides an empty username to OpenVPN (and a password, empty or not), OpenVPN does nothing. That is, it doesn't tell Tunnelblick it is in the "WAIT" state – it doesn't send any status info to Tunnelblick. So nothing happens. OpenVPN doesn't ask for the username again, or complain, or do anything, as far as I can tell. I assume this is a bug in OpenVPN: it should probably accept an empty username and pass it on to the server, but if it doesn't do that, it should at least complain (via the management interface) that empty usernames aren't accepted.

It is not clear to me what would happen to an empty username if your authorization plugin is used, though. Perhaps that would work OK, or perhaps OpenVPN would see the empty username before it sends it to your plugin and then not send it to your plugin. If an empty username gets intercepted this way, since your plugin ignores the username, you could enter "xxx" as the username and save that to the Keychain with an empty password (but not save the password to the Keychain). I think that would work the way you want, even though it looks terrible.

I don't want to allow empty usernames until the presumed OpenVPN bug is fixed, because it leads to what looks like a hang: the server is waiting for the username/password, and Tunnelblick thinks it already sent them. The user can always click "Disconnect", but I don't want to make the user do that. I suppose I could pop up a warning dialog about the empty password (with a "Don't show this again" checkbox) but I'd rather get the OpenVPN bug fixed.

If you are willing to test this, email me at my Gmail address, jkbullard, and I will send you a link to download a test version of Tunnelblick that allows empty usernames and passwords. 

It isn't clear to me how 

[Petiepooo]

Replies inline

On Thursday, 25 February 2016 12:02:57 UTC-5, jkbull...gmail.com wrote:

It is not clear to me what would happen to an empty username if your authorization plugin is used, though. Perhaps that would work OK, or perhaps OpenVPN would see the empty username before it sends it to your plugin and then not send it to your plugin. If an empty username gets intercepted this way, since your plugin ignores the username, you could enter "xxx" as the username and save that to the Keychain with an empty password (but not save the password to the Keychain). I think that would work the way you want, even though it looks terrible.

If Tunnelblick has access to the certificate's CN, perhaps any empty usernames can just be populated with the CN.  The plugin I'm using explicitly states that it uses the cert's CN rather than the provided username, in any case.  For testing, I just enter a or bump any ol' alpha keys on the way to the tab.

 

If you are willing to test this, email me at my Gmail address, jkbullard, and I will send you a link to download a test version of Tunnelblick that allows empty usernames and passwords. 

 Yes, please.  I would love that.  Contacting you off-list.

--

Pete (petiepooo)

[jkbull...gmail.com]

On Monday, February 29, 2016 at 1:32:48 PM UTC-5, Petiepooo wrote:

Replies inline

On Thursday, 25 February 2016 12:02:57 UTC-5, jkbull...gmail.com wrote:

It is not clear to me what would happen to an empty username if your authorization plugin is used, though. Perhaps that would work OK, or perhaps OpenVPN would see the empty username before it sends it to your plugin and then not send it to your plugin. If an empty username gets intercepted this way, since your plugin ignores the username, you could enter "xxx" as the username and save that to the Keychain with an empty password (but not save the password to the Keychain). I think that would work the way you want, even though it looks terrible.

If Tunnelblick has access to the certificate's CN, perhaps any empty usernames can just be populated with the CN.  The plugin I'm using explicitly states that it uses the cert's CN rather than the provided username, in any case.  For testing, I just enter a or bump any ol' alpha keys on the way to the tab.

Tunnelblick usually doesn't have access to the certificate except for a private configuration. But to get to the CN would be a lot of work (find the appropriate inline certificate or the certificate file that is being used, and then parse the certfiicate). So I'm not going to add that. 

[Petiepooo]

If Tunnelblick has access to the certificate's CN, perhaps any empty usernames can just be populated with the CN.  The plugin I'm using explicitly states that it uses the cert's CN rather than the provided username, in any case.  For testing, I just enter a or bump any ol' alpha keys on the way to the tab.

 

Tunnelblick usually doesn't have access to the certificate except for a private configuration. But to get to the CN would be a lot of work (find the appropriate inline certificate or the certificate file that is being used, and then parse the certfiicate). So I'm not going to add that.

 

Barring that, I'm ok with saving the username to the OS keyring so it populates automatically even as it prompts for the password.  It comes up with the username field having focus, so all I have to do is hit enter for a blank password or tab to enter a OTP.

But yes, I'm seeing the same thing.  If the username is blank, it never connects.  If the password is blank, it uses the plugin's default method (push).

Thanks!

[Jim Kleckner]

I'm curious how this turned out.  Were you able to successfully use TOTP with this experimental version?

[JeffB]

This is an old threads but it sounds to me that you are taking the hard path when there is one that I think works pretty well.  I'm using it is with the Duo Radius Auth proxy.  Granted it requires LDAP or Radius or AD but it works out of the box with any openvpn client.

The way that the Auth proxy works is that you configure it to hit your Radius or LDAP directory and for your particular integration.   In Tunnelblick you overload the password field with <password>,<token>    where commonly it would be ,push after your password,  or ,123456 where the numbers are your TOTP.

The auth proxy first checks the Radius or LDAP for correct credentials then it will do the 2FA part via duo.

The only issue I have with tunnelblick is that when users save their password and what they saved has the ,push appended to their password.   If they leave the VPN connected and go to sleep or go out,  if their VPN blips and reconnects it will keep attempting to reconnect over and over until the duo service locks the user out.   It would be ideal if the save password would try to reconnect once then present the dialog instead of retrying over and over to lock out the user.

On Friday, February 19, 2016 at 4:38:54 PM UTC-5, Petiepooo wrote: