Re: [Openvpn-devel] Dynamic challenge/response questions
Hi, On Tue, Jul 24, 2018 at 12:02 AM, Selva Nair wrote: > Hi, > > On Mon, Jul 23, 2018 at 10:58 PM, Jonathan K. Bullard > wrote: >> I was testing Tunnelblick with Selva's C/R server and config (thanks >> again for that) and there was a problem. Maybe I'm (still) >> misunderstanding something, but a SIGUSR1 restart asks for the normal >> username/password instead of a static C/R. >> >> That is, the first thing after the restart is ">PASSWORD:Need 'Auth' >> username/password" instead of ">PASSWORD:Need 'Auth' username/password >> SC:1,Type something (e.g., hello): ". > > I think that's a side effect of my test config using both static challenge and > dynamic challenge together. Not a realistic use case, I suppose. I did > that to keep > the server side verify simple for a quick validation of patches that > touch user-auth. OK; makes sense. > But it was probably not a good approach for properly testing what happens on > signals or during TLS renegotiation. I was testing more than the test was designed to do, so that's understandable. > If you wish I can amend my server side verify script so that you can test > static and dynamic challenge each separately. That would be great, but don't do it just for me. If you do it for yourself, let me know, though, and I'll try it. >> Should Tunnelblick save the static challenge info (like it saves the >> dynamic challenge info) and use it again whenever it sees a >> ">PASSWORD:Need 'Auth' username/password"? (Except when there is also >> a pending dynamic challenge, in which case it would use that instead.) (I tried doing that and all worked well, so I was thinking that was it.) > Normally SIGUSR1 restart should re-prompt with the static challenge if in use. OK, thanks. I won't commit the code that saves and reuses the static C/R info. >> Also, there's an oddity (that doesn't cause a problem) in that the >> first thing Tunnelblick sees over the management interface for the >> original connection is "ENTER PASSWORD:SUCCESS: password is correct" >> -- that comes even before ">INFO:OpenVPN Management Interface Version >> 1 -- type 'help' for more info", and long before any username or >> password has been entered. > > The ENTER PASSWORD: is for the management-password, isn't it? Of course it is. Mystery solved, thanks! Best regards, Jon -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Dynamic challenge/response questions
Hi, On Mon, Jul 23, 2018 at 10:31:03PM -0400, Selva Nair wrote: > On Sat, Jul 21, 2018 at 1:21 PM, Jonathan K. Bullard > wrote: > > > Some, perhaps including Selva's $payingCustomer, may not want to use > > Tunnelblick betas or use OpenVPN 2.5 until it is released. > > I missed this last time... Its Gert who has $$payingCustomer(s) :) Indeed. Unfortunately, most of the time they keep me from working on OpenVPN and demand that I fix their network or IPSEC VPNs or other such nastinesses... :-) - but at least sometimes I can elicit either paid time or other goods (like server CPU+bandwidth) for OpenVPN. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Dynamic challenge/response questions
Hi, On Mon, Jul 23, 2018 at 10:58 PM, Jonathan K. Bullard wrote: > I was testing Tunnelblick with Selva's C/R server and config (thanks > again for that) and there was a problem. Maybe I'm (still) > misunderstanding something, but a SIGUSR1 restart asks for the normal > username/password instead of a static C/R. > > That is, the first thing after the restart is ">PASSWORD:Need 'Auth' > username/password" instead of ">PASSWORD:Need 'Auth' username/password > SC:1,Type something (e.g., hello): ". I think that's a side effect of my test config using both static challenge and dynamic challenge together. Not a realistic use case, I suppose. I did that to keep the server side verify simple for a quick validation of patches that touch user-auth. But it was probably not a good approach for properly testing what happens on signals or during TLS renegotiation. If you wish I can amend my server side verify script so that you can test static and dynamic challenge each separately. > > Should Tunnelblick save the static challenge info (like it saves the > dynamic challenge info) and use it again whenever it sees a > ">PASSWORD:Need 'Auth' username/password"? (Except when there is also > a pending dynamic challenge, in which case it would use that instead.) Normally SIGUSR1 restart should re-prompt with the static challenge if in use. > > Also, there's an oddity (that doesn't cause a problem) in that the > first thing Tunnelblick sees over the management interface for the > original connection is "ENTER PASSWORD:SUCCESS: password is correct" > -- that comes even before ">INFO:OpenVPN Management Interface Version > 1 -- type 'help' for more info", and long before any username or > password has been entered. The ENTER PASSWORD: is for the management-password, isn't it? Selva -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Dynamic challenge/response questions
Hi, On Mon, Jul 23, 2018 at 10:31 PM, Selva Nair wrote: > On Sat, Jul 21, 2018 at 1:21 PM, Jonathan K. Bullard > wrote: > >> Some, perhaps including Selva's $payingCustomer, may not want to use >> Tunnelblick betas or use OpenVPN 2.5 until it is released. > > I missed this last time... Its Gert who has $$payingCustomer(s) :) Oops, sorry. (Sorry you don't have $payingCustomers, too : ) Oh, and sorry for my top-post, too : ( Best regards, Jon -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Dynamic challenge/response questions
I was testing Tunnelblick with Selva's C/R server and config (thanks again for that) and there was a problem. Maybe I'm (still) misunderstanding something, but a SIGUSR1 restart asks for the normal username/password instead of a static C/R. That is, the first thing after the restart is ">PASSWORD:Need 'Auth' username/password" instead of ">PASSWORD:Need 'Auth' username/password SC:1,Type something (e.g., hello): ". Should Tunnelblick save the static challenge info (like it saves the dynamic challenge info) and use it again whenever it sees a ">PASSWORD:Need 'Auth' username/password"? (Except when there is also a pending dynamic challenge, in which case it would use that instead.) Also, there's an oddity (that doesn't cause a problem) in that the first thing Tunnelblick sees over the management interface for the original connection is "ENTER PASSWORD:SUCCESS: password is correct" -- that comes even before ">INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info", and long before any username or password has been entered. Once I get everything working (and I understand it myself), I plan to submit a patch to doc/management-notes.txt that will (I hope) clarify the C/R documentation. Thanks, Jon On Thu, Jul 19, 2018 at 4:22 PM, Selva Nair wrote: > Hi, > > Here is the config. There are no secrets, so just input anything > against the username/password/static challenge prompts (use short > non-empty strings). For dynamic challenge, the answer must be correct > for the connection to succeed. > > If the server is down please ping me. > > Selva > > On Thu, Jul 19, 2018 at 3:14 PM, Gert Doering wrote: >> Hi, >> >> On Thu, Jul 19, 2018 at 02:38:55PM -0400, Selva Nair wrote: >>> On Thu, Jul 19, 2018 at 1:52 PM, Gert Doering wrote: >>> > On Thu, Jul 19, 2018 at 11:43:17AM -0400, Jonathan K. Bullard wrote: >>> >> Thank you, Selva! (Now all I need to do is get it working!) >>> > >>> > Looking very much forward to see this happen :-) >>> > >>> > ($payingCustomer ) >>> >>> Send some ??/$$ from $payingCustomer this way :) >> >> I might elicit some funding for Beer at the Hackathon... *tempt* >> >> (They do already sponsor our fun - all my buildslaves run on their vmware >> farm and eat their bandwith... :-) - just no direct flow of money) >> >>> Jon: I have a server for testing static and dynamic challenge. If >>> interested I can send you a config. Or use access server with a free >>> test license. Mine will just challenge with 1 + 1 = ? kind of >>> questions, nothing fancy. >> >> Interest! (Though I might actually have the config already, just >> never came around to work on it) >> >> gert >> -- >> "If was one thing all people took for granted, was conviction that if you >> feed honest figures into a computer, honest figures come out. Never doubted >> it myself till I met a computer with a sense of humor." >> Robert A. Heinlein, The Moon is a Harsh Mistress >> >> Gert Doering - Munich, Germany >> g...@greenie.muc.de -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Dynamic challenge/response questions
Hi, On Sat, Jul 21, 2018 at 1:21 PM, Jonathan K. Bullard wrote: > Some, perhaps including Selva's $payingCustomer, may not want to use > Tunnelblick betas or use OpenVPN 2.5 until it is released. I missed this last time... Its Gert who has $$payingCustomer(s) :) Selva -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Dynamic challenge/response questions
Thanks, Selva, On Mon, Jul 23, 2018 at 1:30 PM, Selva Nair wrote: > > Hi, > > > On Sat, Jul 21, 2018 at 1:21 PM, Jonathan K. Bullard > wrote: > > Hi, > > > > On Thu, Jul 19, 2018 at 2:38 PM, Selva Nair wrote: > >> Jon: I have a server for testing static and dynamic challenge. If > >> interested I can send you a config. Or use access server with a free > >> test license. Mine will just challenge with 1 + 1 = ? kind of > >> questions, nothing fancy. > > > > Thanks, Selva! Your testing server worked fine and I have Tunnelblick > > doing dynamic challenge/response properly now. > > > > However, dynamic C/R needs to include '--auth-retry interact' to work > > because the default is to fail fatally. From what I understand, the > > configs generated by Open Access Server don't include '--auth-retry > > interact', but apparently OpenVPN GUI for Windows forces that option > > because it can assume that it is always being used interactively. > > Tunnelblick can't assume that because it can be and is used > > non-interactively (for example. to connect to a VPN when the computer > > starts up and nobody is logged in to interact with). > > > > I can think of four ways to deal with this problem: > > > > 1. Have Tunnelblick require that the user include 'auth-retry > > interact' in the OpenVPN configuration file. > > > > 2. Have Tunnelblick guess if the configuration is interactive and, if > > it is, to include '--auth-retry interact' in the command line when > > starting OpenVPN. > > > > 3. Have Tunnelblick send 'auth-retry interact' through the management > > interface as soon as it sees a ">PASSWORD:Verification Failed: 'Auth' > > ['CRV…" message. > > > > 4. Patch OpenVPN so that the connection will be restarted instead of > > getting a fatal error if the error message starts with > > ">PASSWORD:Verification Failed: 'Auth' ['CRV", ignoring --auth-retry. > > This looks like a good suggestion. > > > > > The problem with 3 is that it may not work, or it may work only > > sometimes because of a race between OpenVPN processing the failure > > message and processing the 'auth-retry interact' from the management > > interface. > > > > One problem I see with 4 is that I don't think that OpenVPN code > > (other than in OpenVPN GUI) actually "knows" about dynamic C/R. It > > looks to me to be simply a convention between the OpenVPN GUI (and > > other GUIs) and the scripts that run on the OpenVPN server. It would > > also break a dynamic C/R setup in which 'auth-retry nointeract' was > > specified, or in which no 'auth-retry' was included, but they wouldn't > > be working setups anyway. > > Instead of forcing auth-retry interact, it would be enough to change > the handling of receive_auth_failed() in push.c -- if the "reason" > text contains "AUTH_FAILED,CRV1:" handle it as if AR_INTERACT is > in effect. The reason text is already passed to that function. > > Not doing so looks like an unintentional consequence of the kludgy > way dynamic CR is implemented. > > That way other code paths where auth-retry is used (for private key > password etc.) are not affected. I think that's a much better idea. > > Another problem with 4 is that presumably it wouldn't appear until > > OpenVPN 2.5, which means that it Tunnelblick would require OpenVPN 2.5 > > (which is included in Tunnelblick betas) for dynamic C/R to work. > > Some, perhaps including Selva's $payingCustomer, may not want to use > > Tunnelblick betas or use OpenVPN 2.5 until it is released. > > As an interim measure, you could send auth-retry interact as soon as > tunnelblick connects to the management interface and internally enforce > "auth-retry interact" or "none" if found in the config. Just opt not to count > the CRV1 message as an auth-failure. It may be also necessary > to remember the auth-retry setting in the config and set it back while > disconnecting from management interface. (Facepalm!) That's a great idea, thanks! It will still affect private keys, but I think that's OK because Tunnelblick will cause a private key auth failure to terminate the OpenVPN process, which is much the same as having OpenVPN terminate itself. > > The good things about 4 are that it would be a pretty small patch (I > > think) and it would "automatically" fix what I consider to be an > > OpenVPN configuration error. > > > > 4 is the best solution from a narrow thinking-only-of-Tunnelblick > > perspective. Would you all consider a patch that does 4? > > Yes, I think this would be a sane and useful change. > > Selva -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Dynamic challenge/response questions
Hi, On Sat, Jul 21, 2018 at 1:21 PM, Jonathan K. Bullard wrote: > Hi, > > On Thu, Jul 19, 2018 at 2:38 PM, Selva Nair wrote: >> Jon: I have a server for testing static and dynamic challenge. If >> interested I can send you a config. Or use access server with a free >> test license. Mine will just challenge with 1 + 1 = ? kind of >> questions, nothing fancy. > > Thanks, Selva! Your testing server worked fine and I have Tunnelblick > doing dynamic challenge/response properly now. > > However, dynamic C/R needs to include '--auth-retry interact' to work > because the default is to fail fatally. From what I understand, the > configs generated by Open Access Server don't include '--auth-retry > interact', but apparently OpenVPN GUI for Windows forces that option > because it can assume that it is always being used interactively. > Tunnelblick can't assume that because it can be and is used > non-interactively (for example. to connect to a VPN when the computer > starts up and nobody is logged in to interact with). > > I can think of four ways to deal with this problem: > > 1. Have Tunnelblick require that the user include 'auth-retry > interact' in the OpenVPN configuration file. > > 2. Have Tunnelblick guess if the configuration is interactive and, if > it is, to include '--auth-retry interact' in the command line when > starting OpenVPN. > > 3. Have Tunnelblick send 'auth-retry interact' through the management > interface as soon as it sees a ">PASSWORD:Verification Failed: 'Auth' > ['CRV…" message. > > 4. Patch OpenVPN so that the connection will be restarted instead of > getting a fatal error if the error message starts with > ">PASSWORD:Verification Failed: 'Auth' ['CRV", ignoring --auth-retry. This looks like a good suggestion. > > The problem with 3 is that it may not work, or it may work only > sometimes because of a race between OpenVPN processing the failure > message and processing the 'auth-retry interact' from the management > interface. > > One problem I see with 4 is that I don't think that OpenVPN code > (other than in OpenVPN GUI) actually "knows" about dynamic C/R. It > looks to me to be simply a convention between the OpenVPN GUI (and > other GUIs) and the scripts that run on the OpenVPN server. It would > also break a dynamic C/R setup in which 'auth-retry nointeract' was > specified, or in which no 'auth-retry' was included, but they wouldn't > be working setups anyway. Instead of forcing auth-retry interact, it would be enough to change the handling of receive_auth_failed() in push.c -- if the "reason" text contains "AUTH_FAILED,CRV1:" handle it as if AR_INTERACT is in effect. The reason text is already passed to that function. Not doing so looks like an unintentional consequence of the kludgy way dynamic CR is implemented. That way other code paths where auth-retry is used (for private key password etc.) are not affected. > > Another problem with 4 is that presumably it wouldn't appear until > OpenVPN 2.5, which means that it Tunnelblick would require OpenVPN 2.5 > (which is included in Tunnelblick betas) for dynamic C/R to work. > Some, perhaps including Selva's $payingCustomer, may not want to use > Tunnelblick betas or use OpenVPN 2.5 until it is released. As an interim measure, you could send auth-retry interact as soon as tunnelblick connects to the management interface and internally enforce "auth-retry interact" or "none" if found in the config. Just opt not to count the CRV1 message as an auth-failure. It may be also necessary to remember the auth-retry setting in the config and set it back while disconnecting from management interface. > > The good things about 4 are that it would be a pretty small patch (I > think) and it would "automatically" fix what I consider to be an > OpenVPN configuration error. > > 4 is the best solution from a narrow thinking-only-of-Tunnelblick > perspective. Would you all consider a patch that does 4? Yes, I think this would be a sane and useful change. Selva -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Dynamic challenge/response questions
Hi, On Thu, Jul 19, 2018 at 2:38 PM, Selva Nair wrote: > Jon: I have a server for testing static and dynamic challenge. If > interested I can send you a config. Or use access server with a free > test license. Mine will just challenge with 1 + 1 = ? kind of > questions, nothing fancy. Thanks, Selva! Your testing server worked fine and I have Tunnelblick doing dynamic challenge/response properly now. However, dynamic C/R needs to include '--auth-retry interact' to work because the default is to fail fatally. From what I understand, the configs generated by Open Access Server don't include '--auth-retry interact', but apparently OpenVPN GUI for Windows forces that option because it can assume that it is always being used interactively. Tunnelblick can't assume that because it can be and is used non-interactively (for example. to connect to a VPN when the computer starts up and nobody is logged in to interact with). I can think of four ways to deal with this problem: 1. Have Tunnelblick require that the user include 'auth-retry interact' in the OpenVPN configuration file. 2. Have Tunnelblick guess if the configuration is interactive and, if it is, to include '--auth-retry interact' in the command line when starting OpenVPN. 3. Have Tunnelblick send 'auth-retry interact' through the management interface as soon as it sees a ">PASSWORD:Verification Failed: 'Auth' ['CRV…" message. 4. Patch OpenVPN so that the connection will be restarted instead of getting a fatal error if the error message starts with ">PASSWORD:Verification Failed: 'Auth' ['CRV", ignoring --auth-retry. The problem with 1 is that it means a Windows config will not work with Tunnelblick unless the config is changed. I could add a checkbox to enable it, or to disable it, but that's a pain for users and clutters up the GUI. The problem with 2 is that if the guess is incorrect it will break existing setups and cause them to loop trying to connect instead of simply failing. I could add a checkbox to enable it, or to disable it, but that's a pain for users and clutters up the GUI. The problem with 3 is that it may not work, or it may work only sometimes because of a race between OpenVPN processing the failure message and processing the 'auth-retry interact' from the management interface. One problem I see with 4 is that I don't think that OpenVPN code (other than in OpenVPN GUI) actually "knows" about dynamic C/R. It looks to me to be simply a convention between the OpenVPN GUI (and other GUIs) and the scripts that run on the OpenVPN server. It would also break a dynamic C/R setup in which 'auth-retry nointeract' was specified, or in which no 'auth-retry' was included, but they wouldn't be working setups anyway. Another problem with 4 is that presumably it wouldn't appear until OpenVPN 2.5, which means that it Tunnelblick would require OpenVPN 2.5 (which is included in Tunnelblick betas) for dynamic C/R to work. Some, perhaps including Selva's $payingCustomer, may not want to use Tunnelblick betas or use OpenVPN 2.5 until it is released. The good things about 4 are that it would be a pretty small patch (I think) and it would "automatically" fix what I consider to be an OpenVPN configuration error. 4 is the best solution from a narrow thinking-only-of-Tunnelblick perspective. Would you all consider a patch that does 4? Best regards, and thanks for all your help, Jon -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Dynamic challenge/response questions
Hi, On Thu, Jul 19, 2018 at 02:38:55PM -0400, Selva Nair wrote: > On Thu, Jul 19, 2018 at 1:52 PM, Gert Doering wrote: > > On Thu, Jul 19, 2018 at 11:43:17AM -0400, Jonathan K. Bullard wrote: > >> Thank you, Selva! (Now all I need to do is get it working!) > > > > Looking very much forward to see this happen :-) > > > > ($payingCustomer ) > > Send some ??/$$ from $payingCustomer this way :) I might elicit some funding for Beer at the Hackathon... *tempt* (They do already sponsor our fun - all my buildslaves run on their vmware farm and eat their bandwith... :-) - just no direct flow of money) > Jon: I have a server for testing static and dynamic challenge. If > interested I can send you a config. Or use access server with a free > test license. Mine will just challenge with 1 + 1 = ? kind of > questions, nothing fancy. Interest! (Though I might actually have the config already, just never came around to work on it) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Dynamic challenge/response questions
Hi Arne, (For some reason Gmail put your post in my spam folder, so I just saw it now.) On Thu, Jul 19, 2018 at 11:49 AM, Arne Schwabe wrote: > Am 19.07.18 um 17:43 schrieb Jonathan K. Bullard: >> Thank you, Selva! (Now all I need to do is get it working!) >> > > If you do all that stuff, be sure to also look at static-challenge that > can be part of openvpn files, e.g. > > static-challenge "Please enter your gauth code" 1 Support for static challenge is in the latest Tunnelblick beta (released yesterday) and works as far as I can tell. Dynamic is also in the beta, but doesn't work because I completely misunderstood how it was supposed to work, as evidenced by this thread. Best regards, Jon -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Dynamic challenge/response questions
Hi, Selva, On Thu, Jul 19, 2018 at 2:38 PM, Selva Nair wrote: >> Jon: I have a server for testing static and dynamic challenge. If > interested I can send you a config. Or use access server with a free > test license. Mine will just challenge with 1 + 1 = ? kind of > questions, nothing fancy. Thanks for the offer. Configurations for testing both static and dynamic challenge would be great. Please send them (or directions for downloading them). Best regards, Jon -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Dynamic challenge/response questions
Hi, On Thu, Jul 19, 2018 at 1:52 PM, Gert Doering wrote: > Hi, > > On Thu, Jul 19, 2018 at 11:43:17AM -0400, Jonathan K. Bullard wrote: >> Thank you, Selva! (Now all I need to do is get it working!) > > Looking very much forward to see this happen :-) > > ($payingCustomer ) Send some €€/$$ from $payingCustomer this way :) Jon: I have a server for testing static and dynamic challenge. If interested I can send you a config. Or use access server with a free test license. Mine will just challenge with 1 + 1 = ? kind of questions, nothing fancy. Selva -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Dynamic challenge/response questions
Hi, On Thu, Jul 19, 2018 at 11:43:17AM -0400, Jonathan K. Bullard wrote: > Thank you, Selva! (Now all I need to do is get it working!) Looking very much forward to see this happen :-) ($payingCustomer is using a LinOTP based auth backend which I'd like to make much nicer with static and dynamic challenge-response, but since almost all users are on Tunnelblick today, I was too lazy to tackle it yet :-) ) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Dynamic challenge/response questions
Am 19.07.18 um 17:43 schrieb Jonathan K. Bullard: > Thank you, Selva! (Now all I need to do is get it working!) > If you do all that stuff, be sure to also look at static-challenge that can be part of openvpn files, e.g. static-challenge "Please enter your gauth code" 1 Arne -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Dynamic challenge/response questions
Thank you, Selva! (Now all I need to do is get it working!) Best regards, Jon On Thu, Jul 19, 2018 at 11:39 AM, Selva Nair wrote: > Hi, > > On Thu, Jul 19, 2018 at 10:48 AM, Jonathan K. Bullard > wrote: >> Thank you very much, Selva. >> >> On Wed, Jul 18, 2018 at 10:48 PM, Selva Nair wrote: >> >>> There are two messages involved: >>> >>> 1. First comes the fake auth failure message which contains the >>> challenge string. The format of this is as you have quoted above. The >>> single quoted string between the square brackets is what is actually >>> sent by the server. This should be parsed as >>> >>> CRV1:flags:state_id:base64_username:challenge >>> (note that there is no colon at the end) >>> >>> So in the above example >>> flags = R,E >>> state_id = Om01u7Fh4LrGBS7uh0SWmzwabUiGiW6I >>> base64_username = Y3Ixh >>> challenge = Please enter token PIN: >>> >>> In this case the last colon is a part of the challenge as its not a >>> part of the protocol. >>> >>> As the daemon thinks auth failed, this will trigger a restart. On >>> restart the client openvpn daemon will prompt for username password as >>> usual. So >>> >>> 2. The usual auth prompt comes as >>> PASSWORD:Need 'Auth' username PASSWORD:Need 'Auth' password >>> >>> The GUI should remember that this prompt follows the >>> verification-failure message that contained a CRV1 challenge and be >>> ready to respond accordingly. And should be responded to in the same >>> format as usual user-auth response but this time with the decoded >>> username as username and the specially formatted challenge response >>> (see below) as the password. >> >> I _completely_ misunderstood how this works! I apologize for being so >> dense. >> >> Can you confirm that the following is correct? >> >> 1. When the GUI gets a ">PASSWORD:Verification Failed: 'Auth' >> ['CRV1:…" message, it just stores the info. >> >> 2. Each time after 1., when the GUI gets a ">PASSWORD:Need 'Auth' >> username" request, it responds with the decoded username from the >> stored info. >> >> 3. Each time after 1., when the GUI gets a ">PASSWORD:Need 'Auth' >> password" request, it asks the user for a password (using the prompt >> from the info) and sends that back with the "state_id" from the stored >> info and formatted as described. >> > > Yes, yes and partially yes :) -- instead of each time, make it the "first > time". > (see below) > >> 4. Any later ">PASSWORD:Verification Failed: 'Auth' ['CRV1:…" >> messages overwrite the old info the GUI stored. >> > > Yes. > >> Or do 2. and 3. only happen once, and after that responses to >> ">PASSWORD:Need 'Auth' username" and ">PASSWORD:Need 'Auth' password" >> should revert back to the normal behavior until another >> ">PASSWORD:Verification Failed: 'Auth' ['CRV1:…" message is received? > > One should revert back to the usual auth-user-pass state after > responding to the challenge. So, save the challenge and associated > info on receiving it and clear it on using it. Then the logic would > be: if a saved challenge is present use it to "construct" the response > for 'Auth' requests, else use the usual auth-user-pass procedure. > > Selva -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Dynamic challenge/response questions
Hi, On Thu, Jul 19, 2018 at 10:48 AM, Jonathan K. Bullard wrote: > Thank you very much, Selva. > > On Wed, Jul 18, 2018 at 10:48 PM, Selva Nair wrote: > >> There are two messages involved: >> >> 1. First comes the fake auth failure message which contains the >> challenge string. The format of this is as you have quoted above. The >> single quoted string between the square brackets is what is actually >> sent by the server. This should be parsed as >> >> CRV1:flags:state_id:base64_username:challenge >> (note that there is no colon at the end) >> >> So in the above example >> flags = R,E >> state_id = Om01u7Fh4LrGBS7uh0SWmzwabUiGiW6I >> base64_username = Y3Ixh >> challenge = Please enter token PIN: >> >> In this case the last colon is a part of the challenge as its not a >> part of the protocol. >> >> As the daemon thinks auth failed, this will trigger a restart. On >> restart the client openvpn daemon will prompt for username password as >> usual. So >> >> 2. The usual auth prompt comes as >> >>>PASSWORD:Need 'Auth' username >>>PASSWORD:Need 'Auth' password >> >> The GUI should remember that this prompt follows the >> verification-failure message that contained a CRV1 challenge and be >> ready to respond accordingly. And should be responded to in the same >> format as usual user-auth response but this time with the decoded >> username as username and the specially formatted challenge response >> (see below) as the password. > > I _completely_ misunderstood how this works! I apologize for being so dense. > > Can you confirm that the following is correct? > > 1. When the GUI gets a ">PASSWORD:Verification Failed: 'Auth' > ['CRV1:…" message, it just stores the info. > > 2. Each time after 1., when the GUI gets a ">PASSWORD:Need 'Auth' > username" request, it responds with the decoded username from the > stored info. > > 3. Each time after 1., when the GUI gets a ">PASSWORD:Need 'Auth' > password" request, it asks the user for a password (using the prompt > from the info) and sends that back with the "state_id" from the stored > info and formatted as described. > Yes, yes and partially yes :) -- instead of each time, make it the "first time". (see below) > 4. Any later ">PASSWORD:Verification Failed: 'Auth' ['CRV1:…" > messages overwrite the old info the GUI stored. > Yes. > Or do 2. and 3. only happen once, and after that responses to > ">PASSWORD:Need 'Auth' username" and ">PASSWORD:Need 'Auth' password" > should revert back to the normal behavior until another > ">PASSWORD:Verification Failed: 'Auth' ['CRV1:…" message is received? One should revert back to the usual auth-user-pass state after responding to the challenge. So, save the challenge and associated info on receiving it and clear it on using it. Then the logic would be: if a saved challenge is present use it to "construct" the response for 'Auth' requests, else use the usual auth-user-pass procedure. Selva -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Dynamic challenge/response questions
Thank you very much, Selva. On Wed, Jul 18, 2018 at 10:48 PM, Selva Nair wrote: > There are two messages involved: > > 1. First comes the fake auth failure message which contains the > challenge string. The format of this is as you have quoted above. The > single quoted string between the square brackets is what is actually > sent by the server. This should be parsed as > > CRV1:flags:state_id:base64_username:challenge > (note that there is no colon at the end) > > So in the above example > flags = R,E > state_id = Om01u7Fh4LrGBS7uh0SWmzwabUiGiW6I > base64_username = Y3Ixh > challenge = Please enter token PIN: > > In this case the last colon is a part of the challenge as its not a > part of the protocol. > > As the daemon thinks auth failed, this will trigger a restart. On > restart the client openvpn daemon will prompt for username password as > usual. So > > 2. The usual auth prompt comes as > >>PASSWORD:Need 'Auth' username >>PASSWORD:Need 'Auth' password > > The GUI should remember that this prompt follows the > verification-failure message that contained a CRV1 challenge and be > ready to respond accordingly. And should be responded to in the same > format as usual user-auth response but this time with the decoded > username as username and the specially formatted challenge response > (see below) as the password. I _completely_ misunderstood how this works! I apologize for being so dense. Can you confirm that the following is correct? 1. When the GUI gets a ">PASSWORD:Verification Failed: 'Auth' ['CRV1:…" message, it just stores the info. 2. Each time after 1., when the GUI gets a ">PASSWORD:Need 'Auth' username" request, it responds with the decoded username from the stored info. 3. Each time after 1., when the GUI gets a ">PASSWORD:Need 'Auth' password" request, it asks the user for a password (using the prompt from the info) and sends that back with the "state_id" from the stored info and formatted as described. 4. Any later ">PASSWORD:Verification Failed: 'Auth' ['CRV1:…" messages overwrite the old info the GUI stored. Or do 2. and 3. only happen once, and after that responses to ">PASSWORD:Need 'Auth' username" and ">PASSWORD:Need 'Auth' password" should revert back to the normal behavior until another ">PASSWORD:Verification Failed: 'Auth' ['CRV1:…" message is received? Thanks so much, Selva, Jon -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Dynamic challenge/response questions
Hi,
On Wed, Jul 18, 2018 at 7:46 PM, Jonathan K. Bullard
wrote:
> I'm trying to implement dynamic challenge/response in Tunnelblick and
> have some questions. I've been using the management-interface
> documentation [1] as my guide.
>
> 1. Is what the management interface sends something like (all on one line):
>
>>PASSWORD:Verification Failed: 'Auth'
>>['CRV1:R,E:Om01u7Fh4LrGBS7uh0SWmzwabUiGiW6l:Y3Ix:Please enter token PIN:']
>
> and not just the challenge all by itself?
There are two messages involved:
1. First comes the fake auth failure message which contains the
challenge string. The format of this is as you have quoted above. The
single quoted string between the square brackets is what is actually
sent by the server. This should be parsed as
CRV1:flags:state_id:base64_username:challenge
(note that there is no colon at the end)
So in the above example
flags = R,E
state_id = Om01u7Fh4LrGBS7uh0SWmzwabUiGiW6I
base64_username = Y3Ixh
challenge = Please enter token PIN:
In this case the last colon is a part of the challenge as its not a
part of the protocol.
As the daemon thinks auth failed, this will trigger a restart. On
restart the client openvpn daemon will prompt for username password as
usual. So
2. The usual auth prompt comes as
>PASSWORD:Need 'Auth' username
>PASSWORD:Need 'Auth' password
The GUI should remember that this prompt follows the
verification-failure message that contained a CRV1 challenge and be
ready to respond accordingly. And should be responded to in the same
format as usual user-auth response but this time with the decoded
username as username and the specially formatted challenge response
(see below) as the password.
> 2. Is the final ":" in the above part of the prompt to be shown to the
> user, or is it a delimiter showing the end of the prompt?
Yes
>
>
> 3. Is the response back to the management interface really like this:
>
> Username: cr1 ("Y3Ix" base64 decoded)
> Password: CRV1::Om01u7Fh4LrGBS7uh0SWmzwabUiGiW6l::8675309
No, the management-notes.txt is a bit less explicit here. Its only
indicating what username and password should be returned, not the
format of the reply. The response is in reply to the usual "Auth" username
and password prompts so should be formatted as
username "Auth" cr1
password "Auth" CRV1::Om01u7Fh4LrGBS7uh0SWmzwabUiGiW6l::8675309
where 8675309 is the response to the challenge provided by the user.
>
> I ask because the syntax for the username/password for a
> NON-challenge/response response back to the management interface is
>
> username "Auth" THE_USERNAME
> password "Auth" THE_PASSWORD
>
> which has "username" and "password" in lower-case and without the ":"s.
That description in management-notes.txt means that the text following
Username: should be passed back as username and the text following
Password: as password. It should be returned in the above format is
assumed to be understood --- but, yes, that text could be made more explicit.
>
>
> 4. Can the Username and Password fields sent to the OpenVPN management
> interface be quoted (and must double-quotes within the fields be
> escaped), as with the NON-challenge/response response?
Internally, the username and password are parsed by openvpn the same
way whether its a simple user/password or user/password/challenge or
user/dynamic-challenge-response. That's why in all cases the format is
"username type THE_USERNAME" and "password type THE_PASSWORD". So,
quoting rules are the same in all three cases. The only difference is
THE_PASSWORD is a specially formatted string in case of static and
dynamic challenge responses.
The verification scripts on server side will pick the password apart to isolate
the challenge response but openvpn treats it as an opaque string. As with
everything received from the management, It does, however, pass through the
config parser which does quote processing and unescaping.
OpenVPN-GUI for windows uses this template for the format string to
construct the CRV1 "password" reply:
template = "password \"Auth\" \"CRV1::%s::%s\""
and pass the result though an escape processor before writing to the
management socket. Alternatively you can use single quotes to enclose
the 'THE_PASSWORD'.
Selva
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] Dynamic challenge/response questions
I'm trying to implement dynamic challenge/response in Tunnelblick and
have some questions. I've been using the management-interface
documentation [1] as my guide.
1. Is what the management interface sends something like (all on one line):
>PASSWORD:Verification Failed: 'Auth'
>['CRV1:R,E:Om01u7Fh4LrGBS7uh0SWmzwabUiGiW6l:Y3Ix:Please enter token PIN:']
and not just the challenge all by itself?
2. Is the final ":" in the above part of the prompt to be shown to the
user, or is it a delimiter showing the end of the prompt?
3. Is the response back to the management interface really like this:
Username: cr1 ("Y3Ix" base64 decoded)
Password: CRV1::Om01u7Fh4LrGBS7uh0SWmzwabUiGiW6l::8675309
I ask because the syntax for the username/password for a
NON-challenge/response response back to the management interface is
username "Auth" THE_USERNAME
password "Auth" THE_PASSWORD
which has "username" and "password" in lower-case and without the ":"s.
4. Can the Username and Password fields sent to the OpenVPN management
interface be quoted (and must double-quotes within the fields be
escaped), as with the NON-challenge/response response?
Thanks,
Jon Bullard
[1]
https://openvpn.net/index.php/open-source/documentation/miscellaneous/79-management-interface.html
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
