Home A - Z
Page Index

An Otter Wiki

Blame

ff0586 Samuli Seppänen 2025-02-27 10:29:07 1 
Every now and then people ask about the "TLS Triple Handshake Vulnerability". OpenVPN is not affected, as is explained below (from [this email thread](http://thread.gmane.org/gmane.network.openvpn.devel/8341)).
c4f02d Samuli Seppänen 2025-01-29 08:37:37 2
3
```
46f6a3 Samuli Seppänen 2025-02-27 10:28:25 4
>> 1- Does OpenVPN use a lightweight SSL handshake upon automatic
5
> reconnection?
6
>
7
> No. OpenVPN does not initiate TLS session renegotiation or resumption.
8
> The renegotiation messages in OpenVPN connection logs relate to
9
> OpenVPN's data-session key renegotiations, which are not affected by
10
> this attack. For OpenVPN's control channel, it heavily depends on the
11
> underlying crypto library, either OpenSSL of PolarSSL.
12
>
13
> The OpenSSL builds of OpenVPN however might respond to session
14
> renegotiations initiated by a malicious server, I'm not completely
15
> sure on OpenSSL's behaviour. It is not clear to me whether a
16
> mitm-initiated renegotiation is enough to mount the secure-resumption
17
> attack.
18
>
19
> The PolarSSL builds of OpenVPN have session renegotiation disabled,
20
> and will not participate in session renegotiation at all. These are
21
> thus not affected.
c4f02d Samuli Seppänen 2025-01-29 08:37:37 22
46f6a3 Samuli Seppänen 2025-02-27 10:28:25 23
My understanding, based on discussions with Dr. Stephen Henson of the
24
OpenSSL project, is that OpenVPN (when built with OpenSSL) is protected
25
from the Triple Handshake attack because we declare a verification
26
callback method that verifies the peer certificate.
c4f02d Samuli Seppänen 2025-01-29 08:37:37 27
46f6a3 Samuli Seppänen 2025-02-27 10:28:25 28
The Triple Handshake attack can only succeed if the attacker is able to
29
force a mid-session certificate change that bypasses certificate and
30
identity verification on the client.
c4f02d Samuli Seppänen 2025-01-29 08:37:37 31
32
But because OpenVPN declares a verification callback:
33
46f6a3 Samuli Seppänen 2025-02-27 10:28:25 34
SSL_CTX_set_verify (ctx, SSL_VERIFY_PEER |
35
SSL_VERIFY_FAIL_IF_NO_PEER_CERT, verify_callback);
c4f02d Samuli Seppänen 2025-01-29 08:37:37 36
46f6a3 Samuli Seppänen 2025-02-27 10:28:25 37
and because the OpenVPN verification callback always returns a failure
38
status if peer certificate verification fails, it means that the attack
39
could only succeed if the attacker has a cert and private key already
40
trusted by the client, i.e. the server cert was signed by the CA
41
declared in the client config file, and trusted by other identity checks
42
required by the client config (such as tls-remote, remote-cert-tls,
43
ns-cert-type, etc.). But if this were the case, then the client would
44
already be vulnerable to MiTM attacks, even in the absence of the Triple
45
Handshake attack.
c4f02d Samuli Seppänen 2025-01-29 08:37:37 46
46f6a3 Samuli Seppänen 2025-02-27 10:28:25 47
So given that (a) the verify callback is always called on the client
48
when the server presents a certificate, and (b) the verify callback
49
cannot be bypassed by a mid-session certificate change operation
50
initiated by the server, I think we are safe for now.
c4f02d Samuli Seppänen 2025-01-29 08:37:37 51
46f6a3 Samuli Seppänen 2025-02-27 10:28:25 52
>
53
>> 2- If so, when does OpenVPN do a full handshake vs. lightweight
54
> (abbreviated) handshake?
55
>
56
> See above.
c4f02d Samuli Seppänen 2025-01-29 08:37:37 57
46f6a3 Samuli Seppänen 2025-02-27 10:28:25 58
OpenVPN doesn't rely on SSL/TLS renegotiation and always does a full
59
handshake from scratch when renegotiating.
c4f02d Samuli Seppänen 2025-01-29 08:37:37 60
46f6a3 Samuli Seppänen 2025-02-27 10:28:25 61
>
62
>> 3- Does it renogotiate the master key upon reconnection?
63
>
64
> On any TLS errors reported by OpenSSL, OpenVPN shuts down the previous
65
> TLS session, and starts a new session from scratch. It relies on
66
> OpenSSL to do the master key renegotiation.
c4f02d Samuli Seppänen 2025-01-29 08:37:37 67
```