1.5.7 (1354) - Can't connect

Got a problem with Viscosity or need help? Ask here!

mbazdell

Posts: 3
Joined: Fri Jun 19, 2015 12:53 am

Post by mbazdell » Fri Jun 19, 2015 12:59 am
Hi all,

After the latest update I can no longer connect to my VPN server. I was connected, everything working fine, installed the update, and now I can't connect. I have rebooted my system and verified on an older version that the VPN is still accepting connections.

Code: Select all
Jun 18 10:56:39 AM: State changed to Connecting
Jun 18 10:56:40 AM: Viscosity Windows 1.5.7 (1354)
Jun 18 10:56:40 AM: Running on Microsoft Windows 8.1 Pro
Jun 18 10:56:40 AM: Bringing up interface...
Jun 18 10:56:40 AM: Checking reachability status of connection...
Jun 18 10:56:41 AM: Connection is reachable. Starting connection attempt.
Jun 18 10:56:41 AM: OpenVPN 2.3.7 Windows-MSVC [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Jun 18 2015
Jun 18 10:56:41 AM: library versions: OpenSSL 1.0.2c 12 Jun 2015, LZO 2.09
Jun 18 10:56:42 AM: UDPv4 link local: [undef]
Jun 18 10:56:42 AM: UDPv4 link remote: [AF_INET]xxx.xxx.xxx.xxx:1194
Jun 18 10:56:43 AM: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
[b]Jun 18 10:56:47 AM: TLS_ERROR: BIO read tls_read_plaintext error: error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small[/b]
Jun 18 10:56:47 AM: TLS Error: TLS object -> incoming plaintext read error
Jun 18 10:56:47 AM: TLS Error: TLS handshake failed
Jun 18 10:56:47 AM: SIGUSR1[soft,tls-error] received, process restarting

As I said, it still works fine, but this is the error I'm getting on the latest client. Any ideas?

Eric

User avatar
Posts: 861
Joined: Sun Jan 03, 2010 3:27 am

Post by Eric » Fri Jun 19, 2015 1:30 pm
Hi mbazdell,

OpenSSL includes a number of important security updates, including blocking very, very weak Diffie-Hellman (DH) key lengths (less than 768bits). Weak keys are susceptible to a man-in-the-middle attack known as Logjam, which could result in an attacker decrypting your VPN connection:
https://weakdh.org

OpenSSL will be raising the minimum requirements even further to 1024bits in the next update, however at least 2048bits is recommended for a secure connection.

It appears your connection attempt is being blocked as your OpenVPN server’s DH key length is less than 768bits:

> Jun 18 20:49:24: TLS_ERROR: BIO read tls_read_plaintext error: error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small

I’d strongly recommend regenerating the DH parameters file on your OpenVPN server, or contacting your VPN Provider for further assistance.

Regards,
Eric
Eric Thorpe
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs

Maltz

Posts: 1
Joined: Sat Jun 20, 2015 3:02 am

Post by Maltz » Sat Jun 20, 2015 3:44 am
It appears that ASUS routers generate a 512-bit DH parameter, which is what was causing the error for me (on the Mac version w/ ASUS RT-N66U). Thankfully, it's easy to fix, without replacing the 1024-bit certificates and private key, if you have access to openssl.
  1. This command will generate a 2048-bit DH PEM file. It might take a couple of minutes if you're on an older machine.
    Code: Select all
    openssl dhparam -out dh2048.pem 2048
  2. In the router's OpenVPN configuration, select Advanced Settings, then click on Content Modification of Keys and Certification
  3. The bad news here (at least in my firmware/browser) is that the router's web interface adds HTML encoded linefeeds in the keys (e.g. "
" etc) If you leave them there when you click SAVE, it will screw up the certificates. What I did is copy each certificate to a text editor, global replace the encoded strings with a linefeed, and then copy/replace it back into the browser window. It might be prudent to download a router configuration file before you start this, in case the certs get mangled beyond repair by the poorly written web interface.
  4. Now, just replace the contents of the Diffie Hellman parameters with the file that openssl generated above, and click SAVE. Then I think you also have to click APPLY when that window closes. I did, anyway.
That did it for me. Hope that helps!

mbazdell

Posts: 3
Joined: Fri Jun 19, 2015 12:53 am

Post by mbazdell » Sat Jun 20, 2015 4:56 am
Thanks for the quick response. I see I'm not the only one with this issue either. I figured it was something to do with that but wasn't sure if it was being enforced or not. I've sent a support e-mail to Asus, hopefully they'll come out with an update soon (I doubt it).

Perhaps this could be a feature request (disabled by default) to ignore weak keys, or possibly accept weak keys with a dire warning message? Not sure if this is possible or hardcoded into OpenSSL. Regardless, I appreciate you guys keeping on top of security like this!

mbazdell

Posts: 3
Joined: Fri Jun 19, 2015 12:53 am

Post by mbazdell » Tue Jun 23, 2015 5:30 am
Maltz wrote:
It appears that ASUS routers generate a 512-bit DH parameter, which is what was causing the error for me (on the Mac version w/ ASUS RT-N66U). Thankfully, it's easy to fix, without replacing the 1024-bit certificates and private key, if you have access to openssl.
  1. This command will generate a 2048-bit DH PEM file. It might take a couple of minutes if you're on an older machine.
    Code: Select all
    openssl dhparam -out dh2048.pem 2048
    That did it for me. Hope that helps!
This worked for me as well. Thanks for the tip!

gwrichard

Posts: 1
Joined: Wed Jul 01, 2015 11:15 pm

Post by gwrichard » Wed Jul 01, 2015 11:18 pm
Maltz wrote:
It appears that ASUS routers generate a 512-bit DH parameter, which is what was causing the error for me (on the Mac version w/ ASUS RT-N66U). Thankfully, it's easy to fix, without replacing the 1024-bit certificates and private key, if you have access to openssl.
  1. This command will generate a 2048-bit DH PEM file. It might take a couple of minutes if you're on an older machine.
    Code: Select all
    openssl dhparam -out dh2048.pem 2048
  2. In the router's OpenVPN configuration, select Advanced Settings, then click on Content Modification of Keys and Certification
  3. The bad news here (at least in my firmware/browser) is that the router's web interface adds HTML encoded linefeeds in the keys (e.g. "
" etc) If you leave them there when you click SAVE, it will screw up the certificates. What I did is copy each certificate to a text editor, global replace the encoded strings with a linefeed, and then copy/replace it back into the browser window. It might be prudent to download a router configuration file before you start this, in case the certs get mangled beyond repair by the poorly written web interface.
  4. Now, just replace the contents of the Diffie Hellman parameters with the file that openssl generated above, and click SAVE. Then I think you also have to click APPLY when that window closes. I did, anyway.
That did it for me. Hope that helps!
Just wanted to say thanks for posting this. Regenerating the DH parameters worked, but without your detailed directions I doubt I would have been able to complete the entire process. Thanks!

aarbear5

Posts: 1
Joined: Sun Aug 02, 2015 1:20 pm

Post by aarbear5 » Sun Aug 02, 2015 1:56 pm
Hello,

I'm trying this fix as well, but I am getting caught up on the certificates getting messed up my what I assume is my HTML text editor while entering the new DH parameters generated from OpenSSL.

Could you please describe what you mean by replacing the linebreaks? Is it just as simple as deleting them in the text edit window or is there more to it than that?

And is there a way to generate new certificates if I messed everything up beyond repair? I have an archive copy of my config file that was working, do I have to just copy and paste the certificates back in?

Thanks!

crashingdutchman

Posts: 2
Joined: Thu Aug 20, 2015 10:25 pm

Post by crashingdutchman » Thu Aug 20, 2015 10:27 pm
I'm trying this fix as well, but I am getting caught up on the certificates getting messed up my what I assume is my HTML text editor while entering the new DH parameters generated from OpenSSL.
I have the same problem. Carriage returns and line feeds are automatically inserted. Did you manage to solve it?

SchoolbusVegabond

Posts: 2
Joined: Sun Aug 23, 2015 9:52 pm

Post by SchoolbusVegabond » Sun Aug 23, 2015 10:01 pm
Argh. I've been having this same problem as well.

I've was unable to use OpenVPN after updating the client and I discovered that it was because the DH key used by the Asus OpenVPN server was too short. So, using OpenSSL, I created a valid 2048-bit dh.pem file. I copied that into the box on the OpenVPN key and certificate page on the Asus RT-N66U stock firmware (Firmware Version:3.0.0.4.376_3861) and it's still not working. Reading these forums I used the text editor trick to strip out the HTML codes, and I'm still getting a "Diffle {sic} Hellman parameters field error! Please check the Keys and Certification contents on the Advanced Settings page" error.

I've been working at this for over two weeks and it's driving me batty!

amptron

Posts: 1
Joined: Tue Sep 01, 2015 11:21 am

Post by amptron » Tue Sep 01, 2015 11:37 am
Hi Everyone, First of all, thanks Maltz for posting this. I got my vpn working after weekend of painlessly trying everything.

For those who are still confused, what Maltz means is that when you look at the key in the advanced settings page, it contains html code characters which are not part of the key. In the third step, you have to copy keys from each of the field (except for Diffie Hellman, you'll use the key generated in the step 1) to a text editor. Use Notepad++ or something equivalent. Search through and remove text that start with & (and symbol) and end with ; (semicolon). There are quiet lot of them. Then paste it back into its respective field. Once you have all of them pasted back, then click save and apply settings.

Hopefully, this helps.
15 posts Page 1 of 2