Blinking Tunnelblick icon, "waiting for password" message, connection seems fine: is everything ok?

Alan Franzoni

unread,

Jan 14, 2017, 2:53:54 PM1/14/17

to tunnelblick-discuss

Hello,

some context:

Tunnelblick 3.6.9 on macOS Sierra

I'm using a VPN service which is stuck with BF-CBC algorithm (proxpn) which is vulnerable to the SWEET32 attack; I have read that a decent workaround to this issue is limiting the amount of bytes which are exchanged before key renegotiation; so I added the reneg-bytes option to my client configuration (I have read that is not necessary on modern openvpn clients, but since I use the vpn from different boxes I wanted. The full config (excluding endpoints and certs, which should not matter here) is:

client

dev tun

remote-random

resolv-retry infinite

nobind

auth-nocache

user nobody

group nobody

persist-key

persist-tun

remote-cert-tls server

cipher BF-CBC

keysize 512

comp-lzo

verb 4

tun-mtu 1500

mssfix 1450

auth-user-pass

reneg-sec 0

reneg-bytes 67108864

My username and password is saved in macos keychain; when I click on the vpn config, I can connect without entering anything.

Then, after some minutes (I suppose when the 64MB have been exchanged) the tunnelblick icon starts to blink (like it blinks when connecting), if I move the mouse over it I get a "waiting for password" state, but *the VPN actually seems to be keep working.*.

My important question is:

- Is key renegotiation actually happening? How can I verify that?

If that's just a gui glitch, fine; I want to be sure nothing is going wrong.

Of course, if i remove the "auth-nocache" option the issue never happens.

When the issue happens, I get this in the logs:

2017-01-14 20:43:07 *Tunnelblick: This computer's apparent public IP address changed from XXX before connection to YYYafter connection

2017-01-14 20:46:35 TLS: soft reset sec=-223 bytes=90536622/67108864 pkts=105802/0

2017-01-14 20:46:35 *Tunnelblick: Obtained VPN username and password from the Keychain

2017-01-14 20:46:35 MANAGEMENT: CMD 'username "Auth" "XXXX"'

2017-01-14 20:46:35 MANAGEMENT: CMD 'password [...]'

2017-01-14 20:46:44 VERIFY OK: depth=1, C=US, ST=CA, L=SanFrancisco, O=proXPN Direct, LLC, OU=proxpn.com, CN=proxpn.com, name=proxpn.com, emailAddress=X

2017-01-14 20:46:44 Validating certificate key usage

2017-01-14 20:46:44 ++ Certificate has key usage 00a0, expects 00a0

2017-01-14 20:46:44 VERIFY KU OK

2017-01-14 20:46:44 Validating certificate extended key usage

2017-01-14 20:46:44 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication

2017-01-14 20:46:44 VERIFY EKU OK

2017-01-14 20:46:44 VERIFY OK: depth=0, C=US, ST=CA, L=SanFrancisco, O=proXPN Direct, LLC, OU=proxpn.com, CN=proxpn.com, name=proxpn.com, emailAddress=X

2017-01-14 20:46:45 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1542', remote='link-mtu 48042'

2017-01-14 20:46:45 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 48000'

2017-01-14 20:46:45 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 512 bit key

2017-01-14 20:46:45 WARNING: this cipher's block size is less than 128 bit (64 bit). Consider using a --cipher with a larger block size.

2017-01-14 20:46:45 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

2017-01-14 20:46:45 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 512 bit key

2017-01-14 20:46:45 WARNING: this cipher's block size is less than 128 bit (64 bit). Consider using a --cipher with a larger block size.

2017-01-14 20:46:45 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

2017-01-14 20:46:45 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA

nothing else; the icon keeps blinking.

I get that message in the logs ONCE and ONLY ONCE per connection; it doesn't happen ever again, no matter how much data I transfer.

Thanks.

Tunnelblick developer

unread,

Jan 16, 2017, 7:38:12 AM1/16/17

to tunnelblick-discuss

Thanks for your report and for describing the problem so clearly.

I have a feeling that this is a Tunnelblick problem but that's really just a guess at this point.

I would think OpenVPN should renegotiate the keys periodically, so it maybe the fact that Tunnelblick considers the VPN to be "waiting for password" causes the renegotiation to not take place. One question is whether OpenVPN is actually "waiting for password" (from Tunnelblick) or whether Tunnelblick mistakenly thinks that OpenVPN is "waiting for password" when it is not.

It would help if you could post the full diagnostic info), redacted as needed. Please see Read Before You Post.

Note that "user nobody"/"group nobody" can cause problems when the VPN is disconnected. With those options, OpenVPN will not have the permissions needed to restore routing to its pre-VPN state. Sometimes that can be mitigated by using Tunnelblick's "Reset the primary interface after disconnecting" feature, but that does not work for all setups.

On Saturday, January 14, 2017 at 2:53:54 PM UTC-5, Alan Franzoni wrote:

Hello,
some context:

Tunnelblick 3.6.9 on macOS Sierra

I'm using a VPN service which is stuck with BF-CBC algorithm (proxpn) which is vulnerable to the SWEET32 attack; I have read that a decent workaround to this issue is limiting the amount of bytes which are exchanged before key renegotiation; so I added the reneg-bytes option to my client configuration (I have read that is not necessary on modern openvpn clients, but since I use the vpn from different boxes I wanted. The full config (excluding endpoints and certs, which should not matter here) is:

<snip>

Alan Franzoni

unread,

Jan 20, 2017, 5:00:01 AM1/20/17

to tunnelbli...@googlegroups.com

Hello, I tried removing the user nobody/group nobody from the configuration, but the issue seems totally unrelated. I've updated to tunnelblick 3.6.10 as well, and the issue persists. The full diagnostic log follows:

*Tunnelblick: OS X 10.12.2; Tunnelblick 3.6.10 (build 4760); prior version 3.6.9 (build 4685); Admin user

git commit 9f798839bcb9c9aaaa46591e672280e6bee491a4

Configuration proXPN RANDOM UDP

"Sanitized" condensed configuration file for /Users/alan/Library/Application Support/Tunnelblick/Configurations/proXPN RANDOM UDP.tblk:

client

dev tun

remote-random

resolv-retry infinite

nobind

auth-nocache

persist-key

persist-tun

remote-cert-tls server

cipher BF-CBC

keysize 512

comp-lzo

verb 4

tun-mtu 1500

mssfix 1450

auth-user-pass

reneg-sec 0

reneg-bytes 67108864

remote 151.236.21.12 443

remote 162.253.128.67 443

remote 178.209.52.135 443

remote 185.41.141.171 443

remote 188.172.214.196 443

remote 190.10.8.104 443

remote 196.52.16.2 443

remote 196.52.17.68 443

remote 196.52.18.2 443

remote 196.52.19.241 443

remote 196.52.21.134 443

remote 196.52.21.225 443

remote 196.52.21.65 443

remote 196.52.22.2 443

remote 196.52.23.66 443

remote 209.58.163.41 443

remote 209.58.185.40 443

remote 213.179.208.145 443

remote 213.179.208.146 80

remote 213.179.208.146 443

remote 213.179.208.146 8080

remote 213.179.212.2 443

remote 37.235.49.195 443

remote 45.32.191.165 443

remote 50.7.1.67 443

remote 50.7.88.172 443

remote 78.157.207.138 443

remote 78.157.207.139 80

remote 78.157.207.139 443

remote 78.157.207.139 8080

remote 89.46.102.14 443

remote 94.185.84.38 443

remote 94.185.84.42 443

proto udp

<ca>

[Security-related line(s) omitted]

</ca>

<cert>

[Security-related line(s) omitted]

</cert>

<key>

[Security-related line(s) omitted]

</key>

================================================================================

Non-Apple kexts that are loaded:

Index Refs Address Size Wired Name (Version) UUID <Linked Against>

142 0 0xffffff7f80a2c000 0x7000 0x7000 net.sf.tuntaposx.tap (1.0) 23FDB715-3D0D-3A26-ACBA-E3794C231CB7 <7 5 4 1>

143 0 0xffffff7f80a22000 0x7000 0x7000 net.sf.tuntaposx.tun (1.0) 95DD963D-E23D-3B0F-8DE8-A4D2F6BFA5CC <7 5 4 1>

149 3 0xffffff7f84658000 0x61000 0x61000 org.virtualbox.kext.VBoxDrv (5.1.10) E4C40D1D-4754-3857-98EE-7EED4123C4B0 <7 5 4 3 1>

152 0 0xffffff7f846b9000 0x8000 0x8000 org.virtualbox.kext.VBoxUSB (5.1.10) EFB503A1-5CC3-3092-922A-E752434D418E <151 149 41 7 5 4 3 1>

153 0 0xffffff7f846c1000 0x5000 0x5000 org.virtualbox.kext.VBoxNetFlt (5.1.10) 15F3A6B7-6264-3CBC-ADF7-003CC07FC43D <149 7 5 4 3 1>

154 0 0xffffff7f846c6000 0x6000 0x6000 org.virtualbox.kext.VBoxNetAdp (5.1.10) 7749D835-967A-3F1A-95E2-1A842DDEF80A <149 5 4 1>

155 0 0xffffff7f846cc000 0x6000 0x6000 com.getdropbox.dropbox.kext (1.8.6) 64ED2422-9A10-3C8A-AD9E-474ABB6E87EB <7 5 4 2 1>

159 0 0xffffff7f846f0000 0x19000 0x19000 com.github.osxfuse.filesystems.osxfuse (3.5.4) A300818E-4DF9-37E4-A8A0-FDCE7A8B0C8C <7 5 4 3 1>

================================================================================

There are no unusual files in proXPN RANDOM UDP.tblk

================================================================================

Configuration preferences:

-resetPrimaryInterfaceAfterDisconnect = 1

-keychainHasUsernameAndPassword = 1

-lastConnectionSucceeded = 1

================================================================================

Wildcard preferences:

================================================================================

Program preferences:

launchAtNextLogin = 1

notOKToCheckThatIPAddressDidNotChangeAfterConnection = 0

askedUserIfOKToCheckThatIPAddressDidNotChangeAfterConnection = 1

tunnelblickVersionHistory = (

"3.6.10 (build 4760)",

"3.6.9 (build 4685)",

"3.6.8 (build 4625)"

)

statusDisplayNumber = 0

lastLaunchTime = 506451710.552437

lastLanguageAtLaunchWasRTL = 0

connectionWindowDisplayCriteria = showWhenConnecting

maxLogDisplaySize = 102400

lastConnectedDisplayName = proXPN RANDOM UDP

keyboardShortcutIndex = 1

updateCheckAutomatically = 1

updateSendProfileInfo = 1

NSWindow Frame ConnectingWindow = 785 652 389 187 0 0 1920 1057

detailsWindowFrameVersion = 4760

detailsWindowFrame = {{520, 441}, {920, 468}}

detailsWindowLeftFrame = {{0, 0}, {344, 350}}

detailsWindowViewIndex = 0

detailsWindowConfigurationsTabIdentifier = log

leftNavSelectedDisplayName = proXPN RANDOM UDP

AdvancedWindowTabIdentifier = connectingAndDisconnecting

haveDealtWithSparkle1dot5b6 = 1

haveDealtWithOldTunTapPreferences = 1

haveDealtWithOldLoginItem = 1

SUEnableAutomaticChecks = 1

SUFeedURL = https://www.tunnelblick.net/appcast-s.rss

SUScheduledCheckInterval = 86400

SUSendProfileInfo = 1

SULastCheckTime = 2017-01-20 09:46:00 +0000

SULastProfileSubmissionDate = 2017-01-14 19:27:22 +0000

SUHasLaunchedBefore = 1

WebKitDefaultFontSize = 16

WebKitStandardFont = Times

================================================================================

Tunnelblick Log:

*Tunnelblick: OS X 10.12.2; Tunnelblick 3.6.10 (build 4760); prior version 3.6.9 (build 4685)

2017-01-20 10:46:21 *Tunnelblick: Attempting connection with proXPN RANDOM UDP using shadow copy; Set nameserver = 769; monitoring connection

2017-01-20 10:46:21 *Tunnelblick: openvpnstart start proXPN\ RANDOM\ UDP.tblk 1337 769 0 1 0 1066288 -ptADGNWradsgnw 2.3.14-openssl-1.0.2j

2017-01-20 10:46:21 *Tunnelblick: openvpnstart log:

OpenVPN started successfully. Command used to start OpenVPN (one argument per displayed line):

/Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.14-openssl-1.0.2j/openvpn

--daemon

--log

/Library/Application Support/Tunnelblick/Logs/-SUsers-Salan-SLibrary-SApplication Support-STunnelblick-SConfigurations-SproXPN RANDOM UDP.tblk-SContents-SResources-Sconfig.ovpn.769_0_1_0_1066288.1337.openvpn.log

--cd

/Library/Application Support/Tunnelblick/Users/alan/proXPN RANDOM UDP.tblk/Contents/Resources

--verb

3

--config

/Library/Application Support/Tunnelblick/Users/alan/proXPN RANDOM UDP.tblk/Contents/Resources/config.ovpn

--verb

3

--cd

/Library/Application Support/Tunnelblick/Users/alan/proXPN RANDOM UDP.tblk/Contents/Resources

--management

127.0.0.1

1337

--management-query-passwords

--management-hold

--script-security

2

--up

/Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -r -w -ptADGNWradsgnw

--down

/Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -9 -d -f -m -r -w -ptADGNWradsgnw

2017-01-20 10:46:21 OpenVPN 2.3.14 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Jan 14 2017

2017-01-20 10:46:21 library versions: OpenSSL 1.0.2j 26 Sep 2016, LZO 2.09

2017-01-20 10:46:21 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:1337

2017-01-20 10:46:21 Need hold release from management interface, waiting...

2017-01-20 10:46:21 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1337

2017-01-20 10:46:21 MANAGEMENT: CMD 'pid'

2017-01-20 10:46:21 MANAGEMENT: CMD 'state on'

2017-01-20 10:46:21 MANAGEMENT: CMD 'state'

2017-01-20 10:46:21 MANAGEMENT: CMD 'bytecount 1'

2017-01-20 10:46:21 MANAGEMENT: CMD 'hold release'

2017-01-20 10:46:21 *Tunnelblick: openvpnstart starting OpenVPN

2017-01-20 10:46:21 *Tunnelblick: Established communication with OpenVPN

2017-01-20 10:46:21 *Tunnelblick: Obtained VPN username and password from the Keychain

2017-01-20 10:46:21 MANAGEMENT: CMD 'username "Auth" "XXXX'

2017-01-20 10:46:21 MANAGEMENT: CMD 'password [...]'

2017-01-20 10:46:21 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2017-01-20 10:46:21 Socket Buffers: R=[196724->196724] S=[9216->9216]

2017-01-20 10:46:21 UDPv4 link local: [undef]

2017-01-20 10:46:21 UDPv4 link remote: [AF_INET]196.52.16.2:443

2017-01-20 10:46:21 MANAGEMENT: >STATE:1484905581,WAIT,,,

2017-01-20 10:46:22 MANAGEMENT: >STATE:1484905582,AUTH,,,

2017-01-20 10:46:22 TLS: Initial packet from [AF_INET]196.52.16.2:443, sid=f0b46959 84703c39

2017-01-20 10:46:22 VERIFY OK: depth=1, C=US, ST=CA, L=SanFrancisco, O=proXPN Direct, LLC, OU=proxpn.com, CN=proxpn.com, name=proxpn.com, emailAddress=sup...@proxpn.com

2017-01-20 10:46:22 Validating certificate key usage

2017-01-20 10:46:22 ++ Certificate has key usage 00a0, expects 00a0

2017-01-20 10:46:22 VERIFY KU OK

2017-01-20 10:46:22 Validating certificate extended key usage

2017-01-20 10:46:22 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication

2017-01-20 10:46:22 VERIFY EKU OK

2017-01-20 10:46:22 VERIFY OK: depth=0, C=US, ST=CA, L=SanFrancisco, O=proXPN Direct, LLC, OU=proxpn.com, CN=proxpn.com, name=proxpn.com, emailAddress=sup...@proxpn.com

2017-01-20 10:46:27 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 512 bit key

2017-01-20 10:46:27 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).

2017-01-20 10:46:27 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

2017-01-20 10:46:27 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 512 bit key

2017-01-20 10:46:27 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).

2017-01-20 10:46:27 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

2017-01-20 10:46:27 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA

2017-01-20 10:46:27 [proxpn.com] Peer Connection Initiated with [AF_INET]196.52.16.2:443

2017-01-20 10:46:29 MANAGEMENT: >STATE:1484905589,GET_CONFIG,,,

2017-01-20 10:46:30 SENT CONTROL [proxpn.com]: 'PUSH_REQUEST' (status=1)

2017-01-20 10:46:30 PUSH: Received control message: 'PUSH_REPLY,sndbuf 393216,rcvbuf 393216,comp-lzo no,dhcp-option DNS 10.0.22.1,dhcp-option DNS 10.0.22.2,redirect-gateway,route-gateway 192.168.84.1,topology subnet,ping 10,ping-restart 60,ifconfig 192.168.84.51 255.255.255.0'

2017-01-20 10:46:30 OPTIONS IMPORT: timers and/or timeouts modified

2017-01-20 10:46:30 OPTIONS IMPORT: LZO parms modified

2017-01-20 10:46:30 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified

2017-01-20 10:46:30 Socket Buffers: R=[196724->393216] S=[9216->393216]

2017-01-20 10:46:30 OPTIONS IMPORT: --ifconfig/up options modified

2017-01-20 10:46:30 OPTIONS IMPORT: route options modified

2017-01-20 10:46:30 OPTIONS IMPORT: route-related options modified

2017-01-20 10:46:30 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified

2017-01-20 10:46:30 Opening utun (connect(AF_SYS_CONTROL)): Resource busy

2017-01-20 10:46:30 Opened utun device utun1

2017-01-20 10:46:30 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0

2017-01-20 10:46:30 MANAGEMENT: >STATE:1484905590,ASSIGN_IP,,192.168.84.51,

2017-01-20 10:46:30 /sbin/ifconfig utun1 delete

ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address

2017-01-20 10:46:30 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure

2017-01-20 10:46:30 /sbin/ifconfig utun1 192.168.84.51 192.168.84.51 netmask 255.255.255.0 mtu 1500 up

2017-01-20 10:46:30 /sbin/route add -net 192.168.84.0 192.168.84.51 255.255.255.0

add net 192.168.84.0: gateway 192.168.84.51

2017-01-20 10:46:30 /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -r -w -ptADGNWradsgnw utun1 1500 1542 192.168.84.51 255.255.255.0 init

**********************************************

Start of output from client.up.tunnelblick.sh

Retrieved from OpenVPN: name server(s) [ 10.0.22.1 10.0.22.2 ], search domain(s) [ ] and SMB server(s) [ ] and using default domain name [ openvpn ]

Not aggregating ServerAddresses because running on OS X 10.6 or higher

Setting search domains to 'openvpn' because running under OS X 10.6 or higher and the search domains were not set manually and 'Prepend domain name to search domains' was not selected

Saved the DNS and SMB configurations so they can be restored

Changed DNS ServerAddresses setting from '10.13.4.34 208.67.222.222' to '10.0.22.1 10.0.22.2'

Changed DNS SearchDomains setting from '' to 'openvpn'

Changed DNS DomainName setting from '' to 'openvpn'

Did not change SMB NetBIOSName setting of ''

Did not change SMB Workgroup setting of ''

Did not change SMB WINSAddresses setting of ''

DNS servers '10.0.22.1 10.0.22.2' will be used for DNS queries when the VPN is active

NOTE: The DNS servers do not include any free public DNS servers known to Tunnelblick. This may cause DNS queries to fail or be intercepted or falsified even if they are directed through the VPN. Specify only known public DNS servers or DNS servers located on the VPN network to avoid such problems.

Flushed the DNS cache via dscacheutil

/usr/sbin/discoveryutil not present. Not flushing the DNS cache via discoveryutil

Notified mDNSResponder that the DNS cache was flushed

Setting up to monitor system configuration with process-network-changes

End of output from client.up.tunnelblick.sh

**********************************************

2017-01-20 10:46:34 *Tunnelblick: No 'connected.sh' script to execute

2017-01-20 10:46:34 /sbin/route add -net 196.52.16.2 10.13.1.254 255.255.255.255

add net 196.52.16.2: gateway 10.13.1.254

2017-01-20 10:46:34 /sbin/route delete -net 0.0.0.0 10.13.1.254 0.0.0.0

delete net 0.0.0.0: gateway 10.13.1.254

2017-01-20 10:46:34 /sbin/route add -net 0.0.0.0 192.168.84.1 0.0.0.0

add net 0.0.0.0: gateway 192.168.84.1

2017-01-20 10:46:34 Initialization Sequence Completed

2017-01-20 10:46:34 MANAGEMENT: >STATE:1484905594,CONNECTED,SUCCESS,192.168.84.51,196.52.16.2

2017-01-20 10:46:38 *Tunnelblick process-network-changes: A system configuration change was ignored

2017-01-20 10:46:40 *Tunnelblick: This computer's apparent public IP address changed from 151.8.66.180 before connection to 196.52.16.12 after connection

2017-01-20 10:52:51 TLS: soft reset sec=-384 bytes=67596734/67108864 pkts=112272/0

2017-01-20 10:52:51 *Tunnelblick: Obtained VPN username and password from the Keychain

2017-01-20 10:52:51 MANAGEMENT: CMD 'username "Auth" "XXXXX"'

2017-01-20 10:52:51 MANAGEMENT: CMD 'password [...]'

2017-01-20 10:52:52 VERIFY OK: depth=1, C=US, ST=CA, L=SanFrancisco, O=proXPN Direct, LLC, OU=proxpn.com, CN=proxpn.com, name=proxpn.com, emailAddress=sup...@proxpn.com

2017-01-20 10:52:52 Validating certificate key usage

2017-01-20 10:52:52 ++ Certificate has key usage 00a0, expects 00a0

2017-01-20 10:52:52 VERIFY KU OK

2017-01-20 10:52:52 Validating certificate extended key usage

2017-01-20 10:52:52 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication

2017-01-20 10:52:52 VERIFY EKU OK

2017-01-20 10:52:52 VERIFY OK: depth=0, C=US, ST=CA, L=SanFrancisco, O=proXPN Direct, LLC, OU=proxpn.com, CN=proxpn.com, name=proxpn.com, emailAddress=sup...@proxpn.com

2017-01-20 10:52:53 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 512 bit key

2017-01-20 10:52:53 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).

2017-01-20 10:52:53 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

2017-01-20 10:52:53 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 512 bit key

2017-01-20 10:52:53 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).

2017-01-20 10:52:53 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

2017-01-20 10:52:53 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA

================================================================================

"Sanitized" full configuration file

client

dev tun

remote-random

resolv-retry infinite

nobind

auth-nocache

persist-key

persist-tun

remote-cert-tls server

cipher BF-CBC

keysize 512

comp-lzo

verb 4

tun-mtu 1500

mssfix 1450

auth-user-pass

reneg-sec 0

reneg-bytes 67108864

remote 151.236.21.12 443

remote 162.253.128.67 443

remote 178.209.52.135 443

remote 185.41.141.171 443

remote 188.172.214.196 443

remote 190.10.8.104 443

remote 196.52.16.2 443

remote 196.52.17.68 443

remote 196.52.18.2 443

remote 196.52.19.241 443

remote 196.52.21.134 443

remote 196.52.21.225 443

remote 196.52.21.65 443

remote 196.52.22.2 443

remote 196.52.23.66 443

remote 209.58.163.41 443

remote 209.58.185.40 443

remote 213.179.208.145 443

remote 213.179.208.146 80

remote 213.179.208.146 443

remote 213.179.208.146 8080

remote 213.179.212.2 443

remote 37.235.49.195 443

remote 45.32.191.165 443

remote 50.7.1.67 443

remote 50.7.88.172 443

remote 78.157.207.138 443

remote 78.157.207.139 80

remote 78.157.207.139 443

remote 78.157.207.139 8080

remote 89.46.102.14 443

remote 94.185.84.38 443

remote 94.185.84.42 443

proto udp

<ca>

[Security-related line(s) omitted]

</ca>

<cert>

[Security-related line(s) omitted]

</cert>

<key>

[Security-related line(s) omitted]

</key>

================================================================================

ifconfig output:

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384

options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>

inet 127.0.0.1 netmask 0xff000000

inet6 ::1 prefixlen 128

inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1

nd6 options=201<PERFORMNUD,DAD>

gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280

stf0: flags=0<> mtu 1280

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

ether 98:01:a7:89:ee:47

inet 10.13.1.50 netmask 0xffffff00 broadcast 10.13.1.255

media: autoselect

status: active

en1: flags=963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX> mtu 1500

options=60<TSO4,TSO6>

ether 6a:00:01:e2:7f:d0

media: autoselect <full-duplex>

status: inactive

en2: flags=963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX> mtu 1500

options=60<TSO4,TSO6>

ether 6a:00:01:e2:7f:d1

media: autoselect <full-duplex>

status: inactive

p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304

ether 0a:01:a7:89:ee:47

media: autoselect

status: inactive

awdl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1484

ether a6:0f:d8:0e:8b:25

inet6 fe80::a40f:d8ff:fe0e:8b25%awdl0 prefixlen 64 scopeid 0x8

nd6 options=201<PERFORMNUD,DAD>

media: autoselect

status: active

bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

options=63<RXCSUM,TXCSUM,TSO4,TSO6>

ether 6a:00:01:e2:7f:d0

Configuration:

id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0

maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200

root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0

ipfilter disabled flags 0x2

member: en1 flags=3<LEARNING,DISCOVER>

ifmaxaddr 0 port 5 priority 0 path cost 0

member: en2 flags=3<LEARNING,DISCOVER>

ifmaxaddr 0 port 6 priority 0 path cost 0

media: <unknown type>

status: inactive

utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000

inet6 fe80::6d2a:d9d1:7c5c:53ff%utun0 prefixlen 64 scopeid 0xa

nd6 options=201<PERFORMNUD,DAD>

utun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500

inet 192.168.84.51 --> 192.168.84.51 netmask 0xffffff00

================================================================================

Console Log:

2017-01-20 10:46:00 Tunnelblick[13095] Sparkle: Verified appcast signature

2017-01-20 10:46:18 tunnelblickd[22192] Status = 252 from tunnelblick-helper command 'compareShadowCopy proXPN RANDOM UDP'

2017-01-20 10:46:18 Tunnelblick[13095] tunnelblickd status from compareShadowCopy: 252

2017-01-20 10:46:21 Tunnelblick[13095] Tunnelblick needs to perform an action that requires administrator authorization.

2017-01-20 10:46:21 Tunnelblick[13095] Beginning installation or repair

2017-01-20 10:46:21 Tunnelblick[13095] Installation or repair succeeded; Log:

Tunnelblick installer started 2017-01-20 10:46:21. 3 arguments: 0x0001

/Library/Application Support/Tunnelblick/Users/alan/proXPN RANDOM UDP.tblk

/Users/alan/Library/Application Support/Tunnelblick/Configurations/proXPN RANDOM UDP.tblk

Copied /Users/alan/Library/Application Support/Tunnelblick/Configurations/proXPN RANDOM UDP.tblk

to /Library/Application Support/Tunnelblick/Users/alan/proXPN RANDOM UDP.tblk.temp

Renamed /Library/Application Support/Tunnelblick/Users/alan/proXPN RANDOM UDP.tblk.temp

to /Library/Application Support/Tunnelblick/Users/alan/proXPN RANDOM UDP.tblk

Changed ownership of /Library/Application Support/Tunnelblick/Users/alan/proXPN RANDOM UDP.tblk and its contents from 501:80 to 0:0

Changed permissions from 750 to 755 on /Library/Application Support/Tunnelblick/Users/alan/proXPN RANDOM UDP.tblk

Changed permissions from 750 to 755 on /Library/Application Support/Tunnelblick/Users/alan/proXPN RANDOM UDP.tblk/Contents

Changed permissions from 750 to 755 on /Library/Application Support/Tunnelblick/Users/alan/proXPN RANDOM UDP.tblk/Contents/Resources

Changed permissions from 740 to 700 on /Library/Application Support/Tunnelblick/Users/alan/proXPN RANDOM UDP.tblk/Contents/Resources/config.ovpn

Tunnelblick installer finished without error

2017-01-20 10:46:21 Tunnelblick[13095] Created or updated secure (shadow) copy of configuration file /Users/alan/Library/Application Support/Tunnelblick/Configurations/proXPN RANDOM UDP.tblk

2017-01-20 10:46:21 Tunnelblick[13095] Removed 'proXPN RANDOM UDP-useDownRootPlugin' preference

2017-01-20 10:46:21 Tunnelblick[13095] Keychain item retrieved successfully for service = 'Tunnelblick-Auth-proXPN RANDOM UDP' account = 'username'

2017-01-20 10:46:21 Tunnelblick[13095] Keychain item retrieved successfully for service = 'Tunnelblick-Auth-proXPN RANDOM UDP' account = 'password'

2017-01-20 10:52:51 Tunnelblick[13095] Keychain item retrieved successfully for service = 'Tunnelblick-Auth-proXPN RANDOM UDP' account = 'username'

2017-01-20 10:52:51 Tunnelblick[13095] Keychain item retrieved successfully for service = 'Tunnelblick-Auth-proXPN RANDOM UDP' account = 'password'

--
You received this message because you are subscribed to a topic in the Google Groups "tunnelblick-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tunnelblick-discuss/HTodmWoBaR0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tunnelblick-discuss+unsub...@googlegroups.com.
Visit this group at https://groups.google.com/group/tunnelblick-discuss.
For more options, visit https://groups.google.com/d/optout.

Alan Franzoni

unread,

Jan 20, 2017, 5:00:54 AM1/20/17

to tunnelbli...@googlegroups.com

It seems the mail client added some CRLF. I'm attaching the log file, hoping this makes it easier for you to read it.

2017-01-20 10:46:22 VERIFY OK: depth=1, C=US, ST=CA, L=SanFrancisco, O=proXPN Direct, LLC, OU=proxpn.com, CN=proxpn.com, name=proxpn.com, emailAddress=support@proxpn.com

2017-01-20 10:46:22 Validating certificate key usage
2017-01-20 10:46:22 ++ Certificate has key usage 00a0, expects 00a0
2017-01-20 10:46:22 VERIFY KU OK
2017-01-20 10:46:22 Validating certificate extended key usage
2017-01-20 10:46:22 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2017-01-20 10:46:22 VERIFY EKU OK

2017-01-20 10:46:22 VERIFY OK: depth=0, C=US, ST=CA, L=SanFrancisco, O=proXPN Direct, LLC, OU=proxpn.com, CN=proxpn.com, name=proxpn.com, emailAddress=support@proxpn.com

2017-01-20 10:52:52 VERIFY OK: depth=1, C=US, ST=CA, L=SanFrancisco, O=proXPN Direct, LLC, OU=proxpn.com, CN=proxpn.com, name=proxpn.com, emailAddress=support@proxpn.com

2017-01-20 10:52:52 Validating certificate key usage
2017-01-20 10:52:52 ++ Certificate has key usage 00a0, expects 00a0
2017-01-20 10:52:52 VERIFY KU OK
2017-01-20 10:52:52 Validating certificate extended key usage
2017-01-20 10:52:52 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2017-01-20 10:52:52 VERIFY EKU OK

2017-01-20 10:52:52 VERIFY OK: depth=0, C=US, ST=CA, L=SanFrancisco, O=proXPN Direct, LLC, OU=proxpn.com, CN=proxpn.com, name=proxpn.com, emailAddress=support@proxpn.com

To unsubscribe from this group and all its topics, send an email to tunnelblick-discuss+unsubscribe...@googlegroups.com.

tunnelblick.log

Tunnelblick developer

unread,

Jan 20, 2017, 7:38:32 AM1/20/17

to tunnelblick-discuss

Thank you very much for posting the diagnostic info. That clarifies things a lot.

Regarding "user nobody"/"group nobody": you would only see problems when disconnecting, and your diagnostic info didn't show a disconnection, so it's difficult to say, but it is probable that you are not seeing problems because you have Tunnelblick resetting the primary network interface upon disconnection. Since that works for you, you can go ahead and add those options back into your configuration. Be aware, however, that there are situations in which having them in can cause problems. I think your setup will avoid them but am not 100% sure of that.

As a separate issue, I noticed that you have the tuntaposx kexts loaded, presumably by an old manual installation of tuntaposx or some other VPN software. You might want to remove them; Tunnelblick doesn't use them.

Now, on to the problem that you originally posted:

I think your original diagnosis is correct: the VPN is working properly and the key renegotiation takes place successfully but Tunnelblick is incorrectly indicating that it is still "waiting for password".

This is a bug in Tunnelblick caused by, or at least aggravated by, what seems to be an incomplete API in OpenVPN.

Here's what is happening, in detail:

Tunnelblick shows the "waiting for password" state when OpenVPN asks for a username/password. In most circumstances that happens during the initial setup of the VPN, and OpenVPN then goes through other "states", communicating each new state to Tunnelblick in turn with a "state" message, which culminates in either an "EXITING" state if the connection fails, or a "CONNECTED" state if the connection succeeds. Each time OpenVPN communicates one of these new states to Tunnelblick, Tunnelblick updates the status is shows to the user.

However, when a key renegotiation happens, OpenVPN does not send a "state" message telling Tunnelblick that the renegotiation has finished successfully (or started, for that matter). Because you have "auth-nocache", Tunnelblick gets asked by OpenVPN for the username/password during a renegotiation, so it sets its state as "waiting for username/password" (although it might be better described as "waiting for authentication"). It doesn't get a new state from OpenVPN, so it just leaves itself at that state. Without "auth-nocache", Tunnelblick would not be asked for the username/password, so it would not enter the "waiting for password" state, and you wouldn't see any indication from Tunnelblick that the renegotiation is taking place. If a renegotiation were to fail, Tunnelblick would get an "EXITING" state message from OpenVPN and would respond properly to that.

I will discuss with the OpenVPN folks the possibility of having it send Tunnelblick a "RENEGOTIATE-SUCCESS" message and perhaps "RENEGOTIATE-START" and "RENEGOTIATE-FAIL" messages. I don't think they will be receptive to adding new "states", though, so I will also look into other ways to avoid this problem. In the meantime, I believe you would avoid it by removing "auth-nocache" from your configuration. That way, OpenVPN would keep the username/password and not ask Tunnelblick for it during a renegotiation.

Thanks again for posting the diagnostic info.

On Friday, January 20, 2017 at 5:00:01 AM UTC-5, Alan Franzoni wrote:

Hello, I tried removing the user nobody/group nobody from the configuration, but the issue seems totally unrelated. I've updated to tunnelblick 3.6.10 as well, and the issue persists. The full diagnostic log follows:

*Tunnelblick: OS X 10.12.2; Tunnelblick 3.6.10 (build 4760); prior version 3.6.9 (build 4685); Admin user
git commit 9f798839bcb9c9aaaa46591e672280e6bee491a4

<snip>

Tunnelblick developer

unread,

Jan 21, 2017, 7:00:41 AM1/21/17

to tunnelblick-discuss

Thanks again for reporting this.

The problem was in Tunnelblick. It has nothing to do with OpenVPN.

It only affected the status that Tunnelblick displayed – it did not affect the renegotiation. I have fixed the problem in GitHub commit #a99b5b0; the fix will be included in the next beta release.

It was just a "GUI glitch".

You should be able to see the renegotiation taking place if you look in the log in the Tunnelblick's "VPN Details" window. Here is an extract from such a log showing the renegotiation (to a server that, like yours, uses encryption that is subject to the SWEET32 attack, causing the highlighted warnings):

The initial connection:

2017-01-21 06:40:56 MANAGEMENT: >STATE:1484998856,CONNECTED,SUCCESS,***,***,***,,
2017-01-21 06:41:01 *Tunnelblick process-network-changes: A system configuration change was ignored
2017-01-21 06:41:04 *Tunnelblick: This computer's apparent public IP address changed from *** before connection to *** after connection

First renegotiation:

2017-01-21 06:41:50 TLS: soft reset sec=3540 bytes=5165681/5108864 pkts=7413/0
2017-01-21 06:41:50 VERIFY OK: depth=1, C=GB, ST=LN, L=LONDON, O=m7VPN, CN=m7VPN-CA, emailAddress=***
2017-01-21 06:41:50 VERIFY OK: nsCertType=SERVER
2017-01-21 06:41:50 VERIFY OK: depth=0, C=GB, ST=LN, O=m7VPN, CN=server, emailAddress=***
2017-01-21 06:41:50 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 56 bit key
2017-01-21 06:41:50 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
2017-01-21 06:41:50 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
2017-01-21 06:41:50 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 56 bit key
2017-01-21 06:41:50 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
2017-01-21 06:41:50 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
2017-01-21 06:41:50 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA

Second renegotiation:

2017-01-21 06:44:35 TLS: soft reset sec=3435 bytes=5743631/5108864 pkts=6380/0
2017-01-21 06:44:35 VERIFY OK: depth=1, C=GB, ST=LN, L=LONDON, O=m7VPN, CN=m7VPN-CA, emailAddress=***
2017-01-21 06:44:35 VERIFY OK: nsCertType=SERVER
2017-01-21 06:44:35 VERIFY OK: depth=0, C=GB, ST=LN, O=m7VPN, CN=server, emailAddress=***
2017-01-21 06:44:35 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 56 bit key
2017-01-21 06:44:35 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
2017-01-21 06:44:35 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
2017-01-21 06:44:35 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 56 bit key
2017-01-21 06:44:35 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
2017-01-21 06:44:35 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
2017-01-21 06:44:35 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA

Disconnecting from the VPN:

2017-01-21 06:44:41 *Tunnelblick: Disconnecting; VPN Details… window disconnect button pressed

On Saturday, January 14, 2017 at 2:53:54 PM UTC-5, Alan Franzoni wrote:

<snip>

Alan Franzoni

unread,

Jan 21, 2017, 12:15:07 PM1/21/17

to tunnelbli...@googlegroups.com

great! thanks. I'll test that when the next stable comes out, and report to you what happens on my machine.

--

You received this message because you are subscribed to a topic in the Google Groups "tunnelblick-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tunnelblick-discuss/HTodmWoBaR0/unsubscribe.

To unsubscribe from this group and all its topics, send an email to tunnelblick-discuss+unsub...@googlegroups.com.

László Pál

unread,

Apr 22, 2021, 6:23:17 AM4/22/21

to tunnelblick-discuss

Hi,

It seems the issue is back with the latest MacOS upgrade (11.3). With previous betas it was ok.

When I press "disconnect" I can see the following error

2021-04-22 07:51:46.681947 ERROR: could not read Auth username/password/ok/string from management interface

Any idea how to fix it? It was ok with all the 8 betas of 11.3

Thanks

L:

Tunnelblick developer

unread,

Apr 22, 2021, 6:53:03 AM4/22/21

to tunnelblick-discuss

Please don't report the same problem twice. You reported this at https://groups.google.com/g/tunnelblick-discuss/c/nB957_j9LJo/m/i1K33_S3AAAJ

Reply all

Reply to author

Forward