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 <selva.n...@gmail.com> wrote: > Hi, > > On Thu, Jul 19, 2018 at 10:48 AM, Jonathan K. Bullard > <jkbull...@gmail.com> wrote: >> Thank you very much, Selva. >> >> On Wed, Jul 18, 2018 at 10:48 PM, Selva Nair <selva.n...@gmail.com> wrote: >> <snip> >>> 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
