logs show remote servers with degraded security

We are using PIA apps on our Windows 10 x64 Thinkpads and PIA apps on our Android 8.0 phones.

I followed the instructions on https://www.privateinternetaccess.com/pages/client-support/dd-wrt-openvpn on my current stable DD-WRT v3.0-r32170M kongac router.  I've used other OpenVPNs on this router before without similar problems.

Since our Win10 PCs and Android 8.0 phones are using max security, I started with the files openvpn-strong/ from the link on https://www.privateinternetaccess.com/pages/client-support/ , using remote port 1197.  OpenVPN on my router does seem to work fine, but in the logs I see some troubling indications of degraded security:
20170917 10:21:35 W WARNING: 'link-mtu' is used inconsistently local='link-mtu 1570' remote='link-mtu 1542' 
20170917 10:21:35 W WARNING: 'cipher' is used inconsistently local='cipher AES-256-CBC' remote='cipher BF-CBC' 
20170917 10:21:35 W WARNING: 'auth' is used inconsistently local='auth SHA256' remote='auth SHA1' 
20170917 10:21:35 W WARNING: 'keysize' is used inconsistently local='keysize 256' remote='keysize 128' 

The first WARNING likely is not a problem.  However, it seems the server is using BF-CBC, BlowFish (BF), quite insecure, especially when I'm using certs set for AES-256-CBC!  Also note that the server is using SHA1 instead of SHA256!

When I reset dd-wrt to use openvpn/ (not openvpn-strong/) with port 1198, I got similar results, e.g., I was using AES-128-CBC and that cert, but still the remote was using BF-CBC, BlowFish (BF)?

I then looked at my Windows logs under 'Program Files/pia/logs.  Just do a grep for AES and SHA, and you too will likely see multiple lines like:
openvpn.log:Sun Sep 17 10:22:48 2017 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher BF-CBC'
openvpn.log:Sun Sep 17 10:22:48 2017 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
...
Sun Sep 17 10:04:17 2017 WARNING: 'auth' is used inconsistently, local='auth SH 256', remote='auth SHA1'
Sun Sep 17 10:04:17 2017 Data Channel Encrypt: Using 256 bit message hash 'SHA256' for HMAC authentication

I'm look for the counterpart of openvpn.log on our Androids, but have not found them yet.  This is easier with other OpenVPN apps.  Since the remote servers are the issue, I would be surprised if I got results different from above.

Shouldn't this be corrected?

Comments

  • edited September 18 Posts: 122
    Hi ingber,

    I'm very sorry for the trouble! These warning lines are simply noting the difference in defaults on either end (on your client vs the server) while establishing the connection. However, the client settings are used and override these defaults, so your connection should be established with AES-256-CBC or AES-128-CBC depending on what port you're connecting to.

    If you'd like to confirm this for yourself, you can add the line verb 4 to your OpenVPN configuration and see the establishment lines to see exactly what security the connection's using. For example, these are some typical establishment lines for AES-256-CBC connections:
    Fri Jul 15 19:06:53 2016 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
    Fri Jul 15 19:06:53 2016 Data Channel Encrypt: Using 256 bit message hash 'SHA256' for HMAC authentication
    Fri Jul 15 19:06:53 2016 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
    Fri Jul 15 19:06:53 2016 Data Channel Decrypt: Using 256 bit message hash 'SHA256' for HMAC authentication
    The cipher and hash in these notices are the security the connection's using, rather than the ones in the warning lines above. However, I'll certainly bring this up with our team to see what we can do here to make this more obvious. Again, I'm extremely sorry for any confusion! If you have any other trouble, please feel free to message me.
    Post edited by doaks on
  • Posts: 17
    Doaks:

    Hi. I very much appreciate the info. My experience with my own ovpn server is that the server overrode mismatches, so I didn't consider the reverse.

    I was concerned enough to file a ticket, which now can be ignored.

    Lester
Sign In or Register to comment.