On 15/12/16 16:35, Sebastian Rubenstein wrote: > Hi Steffan > > Thanks for taking the time to explain to me the salient features of > a good encryption/decryption VPN. > >>> tls-client >> >> This means you're using TLS for forward secrecy, and are refreshing you >> data channel keys (at least) hourly. That's good. > > Is "forward secrecy" the same as "Perfect Forward Secrecy"? I have > come across the latter on some websites.
Yes. > How can you tell the data channel keys are refreshed at regular intervals? You will see "Data Channel Encrypt: Cipher ....." lines appearing at regular intervals in the log file, at least with --verb 3. It can also be irregular intervals as well, if --reneg-bytes or --reneg-pkts are used. But the key point is that you see more of those "Data Channel Encrypt: " lines in your logs with the same process ID. >> You're using TLS-auth to protect against mitm attacks on your TLS >> connection, which is very good. key-directing 1 means you are using >> different keys for client-server and server-client traffic, which is >> good too. > > Should I be worried if some VPN providers do NOT use "tls-auth" or > "key-directing 1"? The reason for asking is I have been using > commercial VPN providers for many years and some of them do NOT > provide "tls-auth" or "key-directing 1". Probably no need to be overly concerned, at least when thinking about the client side security. The server side though can benefit more from this feature. But --tls-auth makes it far harder to inject packets, as both client and server will just throw away packets with an unexpected HMAC signature. However, commercial public VPN providers will need to provide the same key to all its users, so if the packet injection comes from a user who managed to get a copy of that --tls-auth key, the protection isn't effective any more. >>> Wed Dec 7 08:27:57 2016 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 >>> ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA >> > > You said that my VPN provider is using 4096 bit RSA based on the > above statement. What about "ECDHE-RSA-AES256-GCM-SHA384"? ECDHE - Elliptic Curve with Diffie Hellman key exchange RSA - using RSA keys AES256 - encryption using AES 256 bit key GCM - with GHASH authentication SHA384 - SHA2 384 bits hashing algorithm This is all good. >> >> So, all in all, very decent setup. Once you move to OpenVPN 2.4 (which >> is nearing release), you switch from --tls-auth to --tls-crypt for some >> "poor-man's" post-quantum security, and use AES-256-GCM for more >> efficiency on the data channel. > > Could you explain in greater detail your statement "use AES-256-GCM > for more efficiency on the data channel"? I'll leave this to Steffan (or JJK). > My VPN provider is already using AES-256-GCM but its technical staff > had told me that I needed to use their version of OpenVPN software > because the community-version 2.3.14 does not offer AES-256-GCM. To > be safe, I declined their offer. We're getting really close releasing v2.4. I'll probably wrap up the 2.4_rc2 later today - ready for a public release during tomorrow, and the final v2.4.0 release is scheduled for Dec 28th [1] unless something really odd and unexpected is showing up. But it has to be a real blocker issue, not a silly uncritical issue So if the VPN provider uses a proper community based version and not their own AES-GCM implementation, this should work quite fine out of the box with v2.4. [1] <https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn24> -- kind regards, David Sommerseth
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
