OpenVPN Support Forum

This forum is to discuss and rate service providers of OpenVPN and similar services. THIS IS NOT A FREE ADVERTISEMENT. All posts have a poll with a rating of 1 to 5, with 5 being best, to rate the quality of service, etc.

Forum rules
1) You must create a poll with 5 options, Do Not Recommend (1), Poor (2), Acceptable (3), Would Recommend (4), Strongly Recommend (5).
2) This is not a free advertisement for providers, but a place to review those providers.
3) Polls which are found to be doctored by providers will be locked to a rating of 1 and the source of the spoofing will be revealed to all, including Google.

If the login password of an OpenVPN provider is not kept secure, is the encryption of the openvpn Internet connection then also potentially breached?

A second part to this question also - tech. support for an OpenVPN provider have just said to me, in respect of keeping an Internet connection secure where a wire tap may have been put in place: "If some one wire taps you, there is almost nothing you can do." Is there any reason OpenVPN software should not keep data encrypted even under these conditions?

gso wrote:If the login password of an OpenVPN provider is not kept secure, is the encryption of the openvpn Internet connection then also potentially breached?

Potentially yes, but not directly.
Every SSL/TLS service makes a key-negotiation out of it's credentials, whether this is a password or some kind of key-material. Out of this handshake both parties agree on some session-key which is used for the actual encryption. So by having the password for the openvpn-service (or the WPA2 key of your wifi!) does not directly compromise the traffic. But i (as an advisory) can connect to the network and do nasty things there.

A second part to this question also - tech. support for an OpenVPN provider have just said to me, in respect of keeping an Internet connection secure where a wire tap may have been put in place: "If some one wire taps you, there is almost nothing you can do." Is there any reason OpenVPN software should not keep data encrypted even under these conditions?

Not true. Ofcourse you can wiretap on an internetconnection and see the encrypted traffic. But when the secret, or private key, is kept real private , there's no other way than brute-forcing the crypto on traffic.
If, on the other hand, the password is known to the advisory, one can replay the traffic and disclose the session-key. Having that one, it's possible to decrypt the data and see the content of the vpn-traffic. Be aware this needs a good knowledge of crypto.

Take a step back and think of this:
Why would IT-departments block all internet-access to there employees, other than through the corporate proxy?
If you can initiate your own outbound SSL/TLS connection, they can't scan the content anymore.

Why would IT-departments block all internet-access to there employees, other than through the corporate proxy?
If you can initiate your own outbound SSL/TLS connection, they can't scan the content anymore.

IT deparments block ALL outgoing traffic for various reasons,
f.e if you are infected with a trojan and the trojan tries to send mail with itself you will
get your ip blacklisted,also they want to filter apps like torrent etc....

mwandelaar wrote:...you can wiretap on an internetconnection and see the encrypted traffic. But when the secret, or private key, is kept real private , there's no other way than brute-forcing the crypto on traffic.
If, on the other hand, the password is known to the advisory, one can replay the traffic and disclose the session-key. Having that one, it's possible to decrypt the data and see the content of the vpn-traffic. Be aware this needs a good knowledge of crypto.

Can I clarify if I understand this correctly - if the password is known then a replay attack can reveal the session key - are not session keys unique to a session? (Excuse my ignorance, I am not a network engineer!)

="gso"Can I clarify if I understand this correctly - if the password is known then a replay attack can reveal the session key - are not session keys unique to a session? (Excuse my ignorance, I am not a network engineer!)

Session-keys are, by it's design, only for that specific session and therefore unique.
Revealing the sessionkey is possible in the situation where *only* password-authentication is used and the password is known to the advisory, although most of the situations openvpn will use some of key-material and in that case you need the private key to rebuild the sessionkey, in order to decrypt the traffic.

Crossposting is fine.
OpenVPN-clients authenticate the server with the "ca" option in the config. This is the certificate who issued the server-certificate. If your https-mitm-proxy breaks up the crypto, it will present another certificate to the client and therefore it will reject the server.

gso wrote: Can I clarify if I understand this correctly - if the password is known then a replay attack can reveal the session key - are not session keys unique to a session? (Excuse my ignorance, I am not a network engineer!)

Session-keys are, by it's design, only for that specific session and therefore unique.
Revealing the sessionkey is possible in the situation where *only* password-authentication is used and the password is known to the advisory, although most of the situations openvpn will use some of key-material and in that case you need the private key to rebuild the sessionkey, in order to decrypt the traffic.

Crossposting is fine.
OpenVPN-clients authenticate the server with the "ca" option in the config. This is the certificate who issued the server-certificate. If your https-mitm-proxy breaks up the crypto, it will present another certificate to the client and therefore it will reject the server.

This needs some clarification, which was not covered in earlier posts.

gso wrote:If the login password of an OpenVPN provider is not kept secure, is the encryption of the openvpn Internet connection then also potentially breached?

No. The username/password is used to authenticate you as a user. If that information is leaked, other persons may only connect to the same server using your credentials. The user credentials is never used as a key for the encryption keys on the VPN tunnel.

Further, when using username/passwords the use of TLS mode in OpenVPN is required. TLS mode ensures that the tunnel data is encrypted with an ephemeral session key, and unless renegotiations have been disabled by the service provider, that encryption key will be rotated at regular intervals. The default in OpenVPN is to renegotiate every hour.

gso wrote:A second part to this question also - tech. support for an OpenVPN provider have just said to me, in respect of keeping an Internet connection secure where a wire tap may have been put in place: "If some one wire taps you, there is almost nothing you can do." Is there any reason OpenVPN software should not keep data encrypted even under these conditions?

A properly configured VPN tunnel which have enabled encryption (which is default in OpenVPN), then the tunnelled network traffic will always be encrypted. If the data is transmitted unencrypted, then the encryption must have been disabled explicitly before the session started. And OpenVPN will complain in the logs if this happens.

Yes, some can wiretap your connection between you and the VPN server. What they will see is a lot of encrypted traffic. That alone is no security statement. The strength of encryption is critical (key length, cipher algorithm used). Further what kind of traffic you submit inside the tunnel may also be revealed based on if the tunnel uses compression (normally not recommended) and if the resulting packet shape fits some patterns. Now, this is quite advanced encryption forensic techniques, and it does not necessarily break the encryption. But this information, when applied, can give enough clues to guess what kind of data exists inside the tunnel - and that can again be used to enhance and speed-up the bruteforce attack on the encrypted packet. But, since the tunnel is renegotiated at regular intervals, such attack will only make it possible to crack the encryption for a single "time window". So if someone have captured 3 hours of your encrypted network traffic where the tunnel is renegotiated every hour and an attacker somehow manages to crack the encryption, it will only work for the packets inside the same block of one hour. The other two hours needs to be cracked independently.

There are several steps you can take to further try to protect yourself. But remember, encryption will never protect your data for infinity. You need to choose an encryption setup which is considered most unlikely to be cracked within a time window where this information is critical and sensitive. For most users, that means 1-5 years - perhaps even down to 6 months. With today's knowledge about ciphers, AES encryption is considered secure. And with OpenVPN v2.4, you get AES-GCM which is even faster and more secure. Combine that with enforced tunnel renegotiation and another new feature in OpenVPN v2.4, --tls-crypt, and you will most likely be able to have your data protected for at least the next 5 years, probably even up to 10 years - unless there is a big breakthrough in quantum computing which provides a reasonable amount of qbits available. (And yes, there is some work happening on encryption in OpenVPN which considers the post-quantum era).

So the bottom line is: use OpenVPN v2.4 on client and servers, ensure the tunnel uses the AES-256-GCM cipher (happens automatically if both sides are v2.4), avoid using --compression/--comp-lzo, ensure --reneg-sec is not disabled and use --tls-crypt. Then you'll be fairly safe for quite some time.