auth-user-pass with file credentials not re-read when tunnel re-start if auth-nocache enabled

[sthornto]

There is a bug/feature in that if you use auth-user-pass with a file and auth-nocache and the tunnel restarts, it will prompt you for the username/password, even if you specify "auth-retry nointeract".

e.g. Using the following three lines when you start openVPN it reads the username/password from a file but if the tunnel restarts then it prompts for the username/password, which does not happen as a daemon and then fails:

auth-user-pass .auth-purevpn
auth-retry nointeract
auth-nocache

(the point of auth-nocache is not to keep the credentials in memory).

If you remove auth-nocache then it works (but credentials are kept in memory), e.g:

auth-user-pass .auth-purevpn
auth-retry nointeract
#auth-nocache

Bug: If the tunnel restarts the authentication should re-read the file credentials if "auth-retry nointeract" is set.

Details of the system in question are shown below.

OS:
Linux earth 3.4.47-2.38-desktop #1 SMP PREEMPT Fri May 31 20:17:40 UTC 2013 (3961086) x86_64 x86_64 x86_64 GNU/Linux

OpenVPN 2.2.2 x86_64-suse-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] built on Dec 14 2011
Originally developed by James Yonan
Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@…>

$ ./configure --host=x86_64-suse-linux-gnu --build=x86_64-suse-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/lib --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --enable-iproute2 --enable-x509-alt-username --enable-password-save --with-lzo-headers=/usr/include/lzo CFLAGS=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -W -Wall -fno-strict-aliasing -fPIE LDFLAGS= -pie -lpam -rdynamic -Wl,-rpath,/usr/lib64/openvpn/plugin/lib

Compile time defines: ENABLE_CLIENT_SERVER ENABLE_DEBUG ENABLE_EUREPHIA ENABLE_FRAGMENT ENABLE_HTTP_PROXY ENABLE_MANAGEMENT ENABLE_MULTIHOME ENABLE_PASSWORD_SAVE ENABLE_PORT_SHARE ENABLE_SOCKS ENABLE_X509ALTUSERNAME USE_CRYPTO USE_LIBDL USE_LZO USE_PKCS11 USE_SSL

Current OpenVPN configuration:

---

client

dev tun
proto udp

persist-key
persist-tun

explicit-exit-notify 2
ifconfig-nowarn

# Connections
remote ukm1...... 53
remote ukm2...... 53
remote-random
float

ca ca.crt
tls-auth Wdc.key
cipher AES-256-CBC
comp-lzo

# Log options
verb 3
mute 30

route-noexec
route-delay 2
route-up openvpn-routes.sh

down openvpn-routes.sh

# Authentication section
auth-user-pass .auth-purevpn
auth-retry nointeract
#auth-nocache

# Mangement and monitoring
management localhost 7501 .auth-monitoring
script-security 2

# Keepalive
ping 10
ping-restart 120

---

VPN log:

Jul 17 17:43:58 earth openvpn[14291]: OpenVPN 2.2.2 x86_64-suse-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] built on Dec 14 2011
Jul 17 17:43:58 earth openvpn[14291]: MANAGEMENT: TCP Socket listening on 127.0.0.1:7501
Jul 17 17:43:58 earth openvpn[14291]: WARNING: No server certificate verification method has been enabled. See ​http://openvpn.net/howto.html#mitm for more info.
Jul 17 17:43:58 earth openvpn[14291]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 17 17:43:58 earth openvpn[14291]: Control Channel Authentication: using 'Wdc.key' as a OpenVPN static key file
Jul 17 17:43:58 earth openvpn[14291]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Jul 17 17:43:58 earth openvpn[14291]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Jul 17 17:43:58 earth openvpn[14291]: LZO compression initialized
Jul 17 17:43:58 earth openvpn[14291]: Control Channel MTU parms [ L:1558 D:166 EF:66 EB:0 ET:0 EL:0 ]
Jul 17 17:43:58 earth openvpn[14291]: Socket Buffers: R=[131072->131072] S=[131072->131072]
Jul 17 17:43:58 earth openvpn[14291]: RESOLVE: NOTE: ukm5-ovpn.purevpn.net resolves to 5 addresses
Jul 17 17:43:58 earth openvpn[14291]: Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
Jul 17 17:43:58 earth openvpn[14291]: Local Options hash (VER=V4): '9e7066d2'
Jul 17 17:43:58 earth openvpn[14291]: Expected Remote Options hash (VER=V4): '162b04de'
Jul 17 17:43:58 earth openvpn[14293]: UDPv4 link local (bound): [undef]:1194
Jul 17 17:43:58 earth openvpn[14293]: UDPv4 link remote: 78.129.156.2:53
Jul 17 17:43:58 earth openvpn[14293]: TLS: Initial packet from 78.129.156.2:53, sid=6aa9b6af 2cc76a32
Jul 17 17:43:58 earth openvpn[14293]: VERIFY OK: depth=1, /C=...
Jul 17 17:43:58 earth openvpn[14293]: VERIFY OK: depth=0, /C=...
Jul 17 17:43:59 earth openvpn[14293]: Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Jul 17 17:43:59 earth openvpn[14293]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jul 17 17:43:59 earth openvpn[14293]: Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Jul 17 17:43:59 earth openvpn[14293]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jul 17 17:43:59 earth openvpn[14293]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Jul 17 17:43:59 earth openvpn[14293]: [Server] Peer Connection Initiated with 78.129.156.2:53
Jul 17 17:44:01 earth openvpn[14293]: SENT CONTROL [Server]: 'PUSH_REQUEST' (status=1)
Jul 17 17:44:01 earth openvpn[14293]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 208.67.222.222,dhcp-option DNS 8.8.4.4,route-gateway 82.145.49.129,topology subnet,ping 10,ping-restart 120,ifconfig 82.145.49.134 255.255.255.128'
Jul 17 17:44:01 earth openvpn[14293]: OPTIONS IMPORT: timers and/or timeouts modified
Jul 17 17:44:01 earth openvpn[14293]: OPTIONS IMPORT: --ifconfig/up options modified
Jul 17 17:44:01 earth openvpn[14293]: OPTIONS IMPORT: route options modified
Jul 17 17:44:01 earth openvpn[14293]: OPTIONS IMPORT: route-related options modified
Jul 17 17:44:01 earth openvpn[14293]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Jul 17 17:44:01 earth openvpn[14293]: ROUTE default_gateway=W.X.Y.Z
Jul 17 17:44:01 earth openvpn[14293]: TUN/TAP device tun9 opened
Jul 17 17:44:01 earth openvpn[14293]: TUN/TAP TX queue length set to 100
Jul 17 17:44:01 earth openvpn[14293]: /bin/ip link set dev tun9 up mtu 1500
Jul 17 17:44:01 earth openvpn[14293]: /bin/ip addr add dev tun9 82.145.49.134/25 broadcast 82.145.49.255
Jul 17 17:44:03 earth openvpn[14293]: Initialization Sequence Completed
Jul 17 18:45:29 earth openvpn[14293]: ERROR: could not read Auth username from stdin
Jul 17 18:45:29 earth openvpn[14293]: Exiting
Jul 17 18:45:29 earth openvpn[14293]: Closing TUN/TAP interface
Jul 17 18:45:29 earth openvpn[14293]: /bin/ip addr del dev tun9 82.145.49.134/25
Jul 17 18:45:29 earth openvpn[14293]: openvpn-routes.sh tun9 1500 1558 82.145.49.134 255.255.255.128 init

[Samuli Seppänen]

I think this more like a feature. If the credentials are stored in a file that's readable by root, but not by the user openvpn runs as after dropping the privileges, rereading the credentials from the file will not be possible. And if the file would be readable by the unprivileged user, then the added security gained by using auth-nocache would be lost.

What we could do is add a mention of this to the man-page to make this more clear.

[Gert Döring]

Actually it is just a bug, which syzzer fixed in

commit ac1cb5bfbb9e09e79fd737bc57999d968d77c5ad
Author: Steffan Karger <steffan@…>
Date: Sat May 23 15:02:25 2015 +0200

Re-read auth-user-pass file on (re)connect if required

Fixes trac #225 ('--auth-user-pass FILE' and '--auth-nocache' problem).

(So this ticket is likely a duplicate of that older one - sthornto, can you test whether this works for you in the release/2.3 branch which is in our git repo?)

[Steffan Karger]

Ah, yes, this is most definitely a duplicate of #225. Since we closed that one as 'fixed', I think we can close this one too. If the patch did not fix the problem, please reopen #225 with an explanation.