#958 closed Bug / Defect (fixed)

OpenVPN client can't connect when using a password with special characters

Reported by: Handle Owned by: selvanair
Priority: major Milestone:
Component: Windows GUI Version: OpenVPN 2.4.4 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: password
Cc:

Description

The OpenVPN client won't connect if a password with (certain?) special characters is used:

Tue Nov 14 21:27:51 2017 OpenVPN 2.4.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Sep 26 2017
Tue Nov 14 21:27:51 2017 Windows version 6.2 (Windows 8 or greater) 64bit
Tue Nov 14 21:27:51 2017 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.10
Enter Management Password:

It doesn't go any further or show any errors, the client will just be stuck in the connecting state.

To reproduce the bug, try to connect using the randomly generated password I was using:

u]KSuBGD+'@5g!H}[ouy{+5wFB^q*%&e

Change History (16)

comment:1 Changed 10 months ago by Gert Döring

How exactly are you calling OpenVPN? From the GUI or from the CLI?

This very much looks like "you're doing something funky with the management interface", but without a bit more info *what* passwort, and how you set it, it's hard to diagnose this further.

comment:2 in reply to:  1 Changed 10 months ago by Handle

Replying to cron2:

How exactly are you calling OpenVPN? From the GUI or from the CLI?

From the GUI

This very much looks like "you're doing something funky with the management interface", but without a bit more info *what* passwort, and how you set it, it's hard to diagnose this further.

I used the password above, copied and pasted it into the dialog asking for the user credentials and then encountered the bug. After changing the password to another one of the same length but without special characers, I still encountered the bug at first. After restarting the OpenVPN GUI I can now log in just fine.

I still think that the first password itself was the cause for the trouble because even after restarting the pc multiple times the problem didn't go away. Maybe copying and pasting it has something to do with it too, I'm not sure.

Last edited 10 months ago by Handle (previous) (diff)

comment:3 Changed 10 months ago by tincantech

CC

comment:4 Changed 10 months ago by selvanair

The password string you posted should pass from the GUI to openvpn without issues.

My guess: for some reason the GUI terminated abnormally leaving an openvpn process running. Did you kill the GUI from task manager or by taskkill?

Tue Nov 14 21:27:51 2017 OpenVPN 2.4.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Sep 26 2017
Tue Nov 14 21:27:51 2017 Windows version 6.2 (Windows 8 or greater) 64bit
Tue Nov 14 21:27:51 2017 library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.10
Enter Management Password:

That is from the log file, not GUI status window, right? The GUI clears the random management password after first use so it can't reconnect to a running instance. If the GUI was forcefully killed, you'll have to kill any running openvpn instances too to get back to a sane state.

Restarting the PC should be more than enough, though..

comment:5 in reply to:  4 Changed 10 months ago by Handle

Replying to selvanair:

My guess: for some reason the GUI terminated abnormally leaving an openvpn process running. Did you kill the GUI from task manager or by taskkill?

No, I didn't kill any process because the GUI was still running normally, except for the bug.

Tue Nov 14 21:27:51 2017 OpenVPN 2.4.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Sep 26 2017
Tue Nov 14 21:27:51 2017 Windows version 6.2 (Windows 8 or greater) 64bit
Tue Nov 14 21:27:51 2017 library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.10
Enter Management Password:

That is from the log file, not GUI status window, right?

That is correct. The GUI status window didn't give an indication of anything happening at all. Apart from that the GUI worked normally, I could still abort the connection process, open the log file or close it.

The reason which made me think the bug was caused by the password is that when I accidentially hit enter with an empty password the connection process started instead of stalling. I then typed various other short passwords which all didn't stall the connection process, whereas copying and pasting the password given above did in every case. The strange thing is that with the new password, which didn't contain any special characters, I briefly experienced the same bug (again, copying and pasting it). After restarting OpenVPN I couldn't reproduce the bug anymore using the new password.

I know this is all a bit vague and probably hard to debug. I was copying the passwords from a textfile that was created on Linux and then opened on a laptop running Windows. Could a hidden character trigger this bug? I was copying the password using STRG + A first because in theory there should have been no other content in the textfile except for the password itself.

EDIT: I found the cause! There seems to be a hidden newline character in the textfile, even though it only contains the password. When opening the textfile on a Windows machine with the editor and marking its whole content using STRG + A, the blinking indicator moves to the next line. Copying and pasting this stalls the connection process of OpenVPN reliably. Marking the password manually and then copying and pasting it doesn't stall it.

Is there some way to catch this case within OpenVPN? I'm still wondering though why gedit seems to place a newline character in there when the only content of the textfile is the password without anything after it.

Last edited 10 months ago by Handle (previous) (diff)

comment:6 Changed 10 months ago by selvanair

I'm still wondering though why gedit seems to place a newline character in there when
the only content of the textfile is the password without anything after it.

The standard (POSIX?) definition of a line requires an ending LF (new line) so most text editors on unix/linux will add a new line at end of file.

The added new line will only make the response appear as two commands with the second one empty (just new line), and should not cause any ill effects. Or so I think -- unless the encoding conversion happening during the cut-n-paste is messing things up --- the password text box expects unicode which the GUI will convert to utf-8 before passing to openvpn and your cut-n-paste clipboard may have data in a yet different encoding -- you said STRG-A is that ctrl-A on a German key board?.

Even then either the GUI or openvpn hanging is not a good thing and unexpected. As soon as the user-auth password response is received openvpn will log "MANAGEMENT: CMD 'password [...]'" if verb >= 3. The log shows nothing of that sort?

comment:7 in reply to:  6 Changed 10 months ago by Handle

Replying to selvanair:

I'm still wondering though why gedit seems to place a newline character in there when
the only content of the textfile is the password without anything after it.

The standard (POSIX?) definition of a line requires an ending LF (new line) so most text editors on unix/linux will add a new line at end of file.

Ah, thanks for the explanation!

you said STRG-A is that ctrl-A on a German key board?.

Yes, that's CTRL + A (mark everything), sorry.

Even then either the GUI or openvpn hanging is not a good thing and unexpected. As soon as the user-auth password response is received openvpn will log "MANAGEMENT: CMD 'password [...]'" if verb >= 3. The log shows nothing of that sort?

With the default verbosity the only output is the one shown in my first post. How can I increase the verbosity when running the OpenVPN GUI?

comment:8 Changed 10 months ago by selvanair

Add 'verb 4' to the config file.

comment:9 Changed 10 months ago by Handle

Here is the log with verbosity set to 4. I omitted the output before the version string because I don't think it is relevant.

Fri Nov 17 17:00:08 2017 us=813707 OpenVPN 2.4.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Sep 26 2017
Fri Nov 17 17:00:08 2017 us=813707 Windows version 6.2 (Windows 8 or greater) 64bit
Fri Nov 17 17:00:08 2017 us=813707 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.10
Enter Management Password:
Fri Nov 17 17:00:08 2017 us=823708 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Fri Nov 17 17:00:08 2017 us=823708 Need hold release from management interface, waiting...
Fri Nov 17 17:00:09 2017 us=314375 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Fri Nov 17 17:00:09 2017 us=423987 MANAGEMENT: CMD 'state on'
Fri Nov 17 17:00:09 2017 us=423987 MANAGEMENT: CMD 'log all on'
Fri Nov 17 17:00:09 2017 us=604231 MANAGEMENT: CMD 'echo all on'
Fri Nov 17 17:00:09 2017 us=604231 MANAGEMENT: CMD 'hold off'
Fri Nov 17 17:00:09 2017 us=604231 MANAGEMENT: CMD 'hold release'
Fri Nov 17 17:00:16 2017 us=263414 MANAGEMENT: CMD 'username "Auth" "Joerg"'
Fri Nov 17 17:00:16 2017 us=313025 MANAGEMENT: CMD 'password [...]'
Fri Nov 17 17:00:16 2017 us=313025 MANAGEMENT: CMD '"'

comment:10 Changed 10 months ago by selvanair

The log looks fine except for the last command sent to management -- it reads as a double quote instead of an empty string that I expected.

I think this is what is happening: when a string containing an LF is copy-pasted, windows encloses it in quotes ("") so what the password field gets is

"actual-password\n"

including the quotes. The GUI will submit that as two lines: "actual-password (including that starting quote) as line 1 and a single character " as line 2. Unfortunately the GUI does not escape quotes but openvpn expects double quotes to be escaped (a known issue) (EDIT: Note true: that was based on an outdated entry in TODO). However, how that leads to a impasse is not clear to me.

May be someone more familiar with command parsing (option parsing) inside openvpn may know.

Copy-paste directly from gedit (say from gedit in linux to a Windows VM) will not reveal this as the "hidden" end-of-file line feed will not get selected and copied in that case.

By the way, to see exactly what is sent to the management, try using the offending string as the username and look at the logs. I do not know any way to get the password displayed in the logs without a custom build.

Last edited 10 months ago by selvanair (previous) (diff)

comment:11 in reply to:  10 Changed 10 months ago by Handle

Replying to selvanair:

By the way, to see exactly what is sent to the management, try using the offending string as the username and look at the logs. I do not know any way to get the password displayed in the logs without a custom build.

Just did that:

Fri Nov 17 21:34:21 2017 us=568235 OpenVPN 2.4.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Sep 26 2017
Fri Nov 17 21:34:21 2017 us=568235 Windows version 6.2 (Windows 8 or greater) 64bit
Fri Nov 17 21:34:21 2017 us=568235 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.10
Enter Management Password:
Fri Nov 17 21:34:21 2017 us=568235 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Fri Nov 17 21:34:21 2017 us=568235 Need hold release from management interface, waiting...
Fri Nov 17 21:34:22 2017 us=55356 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Fri Nov 17 21:34:22 2017 us=165573 MANAGEMENT: CMD 'state on'
Fri Nov 17 21:34:22 2017 us=165573 MANAGEMENT: CMD 'log all on'
Fri Nov 17 21:34:22 2017 us=345795 MANAGEMENT: CMD 'echo all on'
Fri Nov 17 21:34:22 2017 us=345795 MANAGEMENT: CMD 'hold off'
Fri Nov 17 21:34:22 2017 us=345795 MANAGEMENT: CMD 'hold release'
Fri Nov 17 21:34:31 2017 us=587321 MANAGEMENT: CMD 'username "Auth" "u]KSuBGD+'@5g!H}[ouy{+5wFB^q*%&e'
Fri Nov 17 21:34:31 2017 us=587321 MANAGEMENT: CMD '"'
Fri Nov 17 21:34:31 2017 us=597280 MANAGEMENT: CMD 'password [...]'

comment:12 Changed 10 months ago by selvanair

OK, thanks for confirming that Windows is adding quotes to the string.
Edit: Wrong conclusion by me: the quotes are added by the GUI but the end result is the same -- embedded '\n' breaks the string into two and leads to unbalanced quotes.

Here is why the connection appears to be hung:

In this case the command/option parser will respond with an error message saying unbalanced quotes. But for reasons I've never understood, openvpn outputs "option errors" in a different format than normal logs and thus do not get parsed by the GUI. At that point openvpn is forever waiting for password while the GUI thinks it has successfully submitted one.

A bug that needs to be addressed. Once fixed all that you will get back is a user authentication failure and re-prompt for username password, as the pasted password will be wrong. But that would be saner than the mysterious impasse.

Last edited 10 months ago by selvanair (previous) (diff)

comment:13 Changed 10 months ago by selvanair

@Handle: I've made a patched GUI that validates user inputs such as password and username. Could you please test it? A test executable is in this pre-release https://github.com/selvanair/openvpn-gui/releases/tag/v11-validate-input

comment:14 in reply to:  13 Changed 10 months ago by Handle

Replying to selvanair:

@Handle: I've made a patched GUI that validates user inputs such as password and username. Could you please test it? A test executable is in this pre-release https://github.com/selvanair/openvpn-gui/releases/tag/v11-validate-input

The validation works for both the username and the password field :) My copied string with the new line character inside is recognized and the error message pops up.

comment:15 Changed 10 months ago by selvanair

Owner: set to selvanair
Status: newaccepted

Thanks for testing.

The patch for the GUI is now submitted as PR 194
https://github.com/OpenVPN/openvpn-gui/pull/194

comment:16 Changed 10 months ago by selvanair

Resolution: fixed
Status: acceptedclosed

Username/password input validation is now in the GUI -- should become available in the next release.

Closing this. Reopen if needed.

Note: See TracTickets for help on using tickets.