Every now and then people ask about the "TLS Triple Handshake Vulnerability". OpenVPN is not affected, as is explained below (from ​this email thread).

>> 1- Does OpenVPN use a lightweight SSL handshake upon automatic 
> reconnection?
>
> No. OpenVPN does not initiate TLS session renegotiation or resumption. 
> The renegotiation messages in OpenVPN connection logs relate to 
> OpenVPN's data-session key renegotiations, which are not affected by 
> this attack. For OpenVPN's control channel, it heavily depends on the 
> underlying crypto library, either OpenSSL of PolarSSL.
>
> The OpenSSL builds of OpenVPN however might respond to session 
> renegotiations initiated by a malicious server, I'm not completely 
> sure on OpenSSL's behaviour. It is not clear to me whether a 
> mitm-initiated renegotiation is enough to mount the secure-resumption 
> attack.
>
> The PolarSSL builds of OpenVPN have session renegotiation disabled, 
> and will not participate in session renegotiation at all. These are 
> thus not affected.

My understanding, based on discussions with Dr. Stephen Henson of the 
OpenSSL project, is that OpenVPN (when built with OpenSSL) is protected 
from the Triple Handshake attack because we declare a verification 
callback method that verifies the peer certificate.

The Triple Handshake attack can only succeed if the attacker is able to 
force a mid-session certificate change that bypasses certificate and 
identity verification on the client.

But because OpenVPN declares a verification callback:

SSL_CTX_set_verify (ctx, SSL_VERIFY_PEER | 
SSL_VERIFY_FAIL_IF_NO_PEER_CERT, verify_callback);

and because the OpenVPN verification callback always returns a failure 
status if peer certificate verification fails, it means that the attack 
could only succeed if the attacker has a cert and private key already 
trusted by the client, i.e. the server cert was signed by the CA 
declared in the client config file, and trusted by other identity checks 
required by the client config (such as tls-remote, remote-cert-tls, 
ns-cert-type, etc.).  But if this were the case, then the client would 
already be vulnerable to MiTM attacks, even in the absence of the Triple 
Handshake attack.

So given that (a) the verify callback is always called on the client 
when the server presents a certificate, and (b) the verify callback 
cannot be bypassed by a mid-session certificate change operation 
initiated by the server, I think we are safe for now.

>
>> 2- If so, when does OpenVPN do a full handshake vs. lightweight 
> (abbreviated) handshake?
>
> See above.

OpenVPN doesn't rely on SSL/TLS renegotiation and always does a full 
handshake from scratch when renegotiating.

>
>> 3- Does it renogotiate the master key upon reconnection?
>
> On any TLS errors reported by OpenSSL, OpenVPN shuts down the previous 
> TLS session, and starts a new session from scratch. It relies on 
> OpenSSL to do the master key renegotiation.