Hi, Selva. Thanks. Comments below.
On Thu, Jun 28, 2018 at 11:56 AM, Selva Nair <selva.n...@gmail.com> wrote:
> Hi,
>
> Currently OpenVPN core supports dynamic CR from console input
> and the Windows OpenVPN-GUI also supports it. The following
> comments are based on those implementations:
>
> On Wed, Jun 27, 2018 at 5:56 PM, Jonathan K. Bullard
> <jkbull...@gmail.com> wrote:
>>
>> Hi.
>>
>> I'm hoping to implement challenge/response ("CR") in Tunnelblick (GUI
>> for OpenVPN on macOS) and have some questions after reading the
>> documentation [1];
>>
>> 1. In Dynamic CR, does requiring a response mean that a non-empty
>> response is required?
>
>
> If by empty you mean the user enters an empty response so that the GUI
> would have to send back
>
> username Auth username
> password Auth CRV1::state_id:: <-- empty response
>
> it's fine. That's what would happen if the user enters just "return key"
> when console prompts for a response. The Windows GUI also does the
> same if the user input is empty. The authentication will likely
> fail but its up to the user to enter a response or not.
Yeah, that's what I figured. Thanks for confirming.
>> 2. In Dynamic CR, what is the purpose of _not_ requiring a response?
>> Is it to display a message without a text input box and have the user
>> only able to click "OK" or "Cancel" (and disconnect if the user clicks
>> "Cancel")? Or should I display a text input box but allow the user to
>> leave it empty (and send an empty "response" to the server?)
>
> I do not know.
>
> I suspect this feature is not used by any server-side implementations
> in use. IIRC, the console prompting just ignores this flag and prompts
> for a response in all cases.
>
> In OpenVPN-GUI I decided to handle this slightly differently: we ignore the
> dynamic CR request if no response is required. So, any subsequent auth
> request will get treated like a normal username/pasword prompt which,
> I think, is the intended behaviour. However, instead of silently ignoring it,
> popping up a notification that displays the "challenge text" could be
> considered.
I'm going to have Tunnelblick display the message. It could be used to
make an announcement (for example, "The VPN will be down for
maintenance…") that doesn't really need to be acknowledged before
allowing the connection to proceed.
>> 3. In Dynamic CR, what is the purpose of passing the username from the
>> server to the client and then back to the server? For example, am I
>> supposed to display the username along with the challenge?
>
>
> Here is my guess: as you might have guessed, dynamic CR is implemented
> using the same logic as that of auth-user-pass prompting and associated
> handshake between client and server.
>
> step 1: auth-user-pass exchange which sets the username
> of the connection at the server side, verifies password
>
> setp 2: send a auth-failure with a specially crafted reason
>
> step 3: repeat step 1
>
> In step 3, the client and the server-side password verification helper
> (management client auth) knows its a challenge-response, but
> the core server code treats it just like a username/password
> request.
>
> Such a flow obviously requires the username to be sent a second time,
> and including that in the CR handshake makes it easier for the client.
Ah, I see. OK!
> That said, the client implementation should not assume that the username
> is the same string as what was sent with in the previous auth-user-pass
> stage. It usually is, but the client should just echo back (after
> base64 decoding etc.) what is received in the challenge string.
> Although, I think, no server-side implementation would change the
> username as that could break things like --username-as-common-name etc.
Yes, that's not a problem.
>> 4. Are there any conventions about the "challenge" string? For
>> example, should "\n" be interpreted as a newline?
>
>
> This is not defined in the specs. In OpenVPN-GUI I just treat it as a
> UTF-8 string and display in a single line text control. Embedded control
> characters will not show up correctly and multiply escaped "\n" that makes
> it to the GUI (after being parsed by openvpn) may display literally as "\n".
>
> I think its fair to assume that the challenge is a "not too long", single line
> text that you could display word-wrapped if necessary.
OK. I'll just leave it alone. My UIs are flexible, so the length doesn't matter.
>> 5. Other than not being a great workflow, is there any problem with
>> displaying the static CR in a separate dialog after the
>> username/password have been entered?
>
> Apart from possibly poor UX, I see no problem with it. On Windows we
> use a single dialog with three input fields (username, password and
> a field labelled by the challenge text).
Yeah, that's what I would have done. But the code that was contributed
did it as a separate dialog, so I'll start with that and see if folks
complain. For users that store the username and password in the macOS
Keychain it's probably better – they'll only be presented with the
challenge dialog, which is simpler than a username/password/challenge
dialog would be.
Thanks again,
Jon
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
