SparkLabs Forum.

Community Help.

Keep getting disconnected since updating to 1.7.10 (1459) to

I updated to the latest version this morning and since then have been getting disconnected roughly every 10 to 20 mins and forcing me to quit viscosity and restart it again. I've taken some of the advice re ping and ping restart times, both of which were 0 before I changed them to the suggested 10 and 3600 which hasn't made a difference. My log keeps showing the message

2018-07-05 15:55:58: 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).

I don't know if it's connected to the disconnection as i've never looked at the log previously so have never seen it before today.

I just restarted viscosity a moment ago and the log gave the following

2018-07-05 15:57:12: Viscosity Mac 1.7.10 (1459)
2018-07-05 15:57:12: Viscosity OpenVPN Engine Started
2018-07-05 15:57:12: Running on macOS 10.13.5
2018-07-05 15:57:12: ---------
2018-07-05 15:57:12: State changed to Connecting
2018-07-05 15:57:12: Checking reachability status of connection...
2018-07-05 15:57:12: Connection is reachable. Starting connection attempt.
2018-07-05 15:57:13: OpenVPN 2.4.6 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on Jun 25 2018
2018-07-05 15:57:13: library versions: OpenSSL 1.0.2o 27 Mar 2018, LZO 2.10
2018-07-05 15:57:14: TCP/UDP: Preserving recently used remote address: [AF_INET]
2018-07-05 15:57:14: UDP link local: (not bound)
2018-07-05 15:57:14: UDP link remote: [AF_INET]
2018-07-05 15:57:14: State changed to Authenticating
2018-07-05 15:57:14: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2018-07-05 15:57:14: [55632666ad615ef54ea928bfe11bedb6] Peer Connection Initiated with [AF_INET]
2018-07-05 15:57:15: 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).
2018-07-05 15:57:15: 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).
2018-07-05 15:57:15: WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.
2018-07-05 15:57:15: Opened utun device utun10
2018-07-05 15:57:15: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
2018-07-05 15:57:15: /sbin/ifconfig utun10 delete
2018-07-05 15:57:15: NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2018-07-05 15:57:15: /sbin/ifconfig utun10 mtu 1500 netmask up
2018-07-05 15:57:15: Initialization Sequence Completed
2018-07-05 15:57:15: DNS mode set to Full
2018-07-05 15:57:16: State changed to Connected

I am on the latest Mac software 10.13.5

many thanks
Hi kinny,

Yes, what you're seeing is related to the SWEET32 warnings. You're most likely using two-factor authentication (via the username/password prompt) and/or session tokens are enabled on the server for another reason, which is clashing with OpenVPN's attempt to mitigate the SWEET32 attack. I've included a discussion of what is going on below, along with a few ways to resolve it.

Basically, SWEET32 is an attack against the older encryption cipher OpenVPN used to default to (BF-CBC). The server you're connecting to is set up to still use it, which is why you're seeing the warnings. To help reduce the likelihood of a successful attack against this old cipher, OpenVPN will by default change your connection to "renegotiate" every 64 MB of traffic through the connection. In your case you're hitting the 64 MB amount every 10 to 20 mins.

A renegotiation is a bit like a reconnection, where a new encryption key is renegotiated. However, this means when a renegotiation attempt occurs you also need to authenticate again with the OpenVPN server. OpenVPN caches a copy of your username and password and sends this along again automatically so you don't need to be prompted constantly. However, if you're using two-factor authentication where these details change each time, then they'll no longer be seen as valid by the OpenVPN server and you'll be disconnected.

There are a number of ways to can resolve this:

1. Get in touch with the administrator of your OpenVPN server and let them know that their current setup is vulnerable to the SWEET32 attack, and that they should change to a more secure cipher, such as AES-256-CBC. This can be done in a backwards compatible way by upgrading the OpenVPN server to version 2.4 and enabling cipher negotiation (so any other older clients connecting will not lose access). More information can be found at:

2. For a quick fix, you can simply add the command "reneg-bytes 0" (without the quotes) as an advanced command to your connection. This will disable OpenVPN's renegotiation every 64 MB of traffic. See the guide below for how to specify advanced commands. However this does make your traffic theoretically vulnerable to the SWEET32 attack, so we do highly encourage the setup be changed to use a secure cipher instead. ... n-commands

3. Add the command "auth-nocache" (without quotes) as an advanced command to your connection. This means instead of being disconnected you'll instead be prompted for your username and password each time a renegotiation attempt occurs.

Finally, the above SWEET32 warnings and renegotiations were taking place in Viscosity 1.7.9 as well. However, you've probably not noticed them until version 1.7.10, as OpenVPN was making use of "session tokens". Instead of caching the username and password it cached a unique token representing your VPN session, and used this in place of the username and password when a renegotiation occurred. However we've opted to disable session tokens being used for renegotiations in version 1.7.10 (they're still used when fully reconnecting, sleeping and then waking your computer, etc.) as there were a number of problems with the implementation in the current OpenVPN version (e.g. handling expired tokens). Their use is expected to be fixed in the next OpenVPN update.

Hi James

Thank you so much for the reply and your explanation. Much appreciated.
I have contacted PIA and they have given me new configurations to AES-256-CBC ciphers to try. After a bit of confusion it seems to be holding so far. I'll let you know if it falls over again.

Many thanks
3 posts Page 1 of 1

Copyright © 2016 SparkLabs Pty Ltd. All Rights Reserved. Privacy Policy