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