Reference Guide

SSL/TLS Communications 9
RSA BSAFE SSL-J 6.2.6 Security Best Practices Guide
Triple Handshake Vulnerability
The triple handshake attack is a vulnerability that might allow a Man-in-the-Middle to
insert data into the first application message after renegotiation with a client
certificate.
The attack relies on the client not recognizing that the server certificate changes from
the fake Man-in-the-Middle certificate to the real server certificate.
The attack proceeds in three steps:
1. A complete handshake with a Man-in-the-Middle occurs. The Man-in-the-Middle
collects all the data required to calculate the connection keys, including the client
random value, the server random value, and the master key.
2. The client reconnects to the server through the Man-in-the-Middle and asks to
resume the handshake. The server certificate is not used during this handshake,
but the Man-in-the-Middle has the connection keys and is able to see all the data.
3. The server demands a renegotiation to allow the client to present a client
certificate. The server certificate is supplied to the client, and the client certificate
is provided to the server.
The Man-in-the-Middle has the keys and can decrypt the handshake packets, and
can add in an application data packet during renegotiation. The server performs
the renegotiation and sees the application data as having come after the
presentation of the client certificate.
The client is now communicating over a client-authenticated channel with the server
and the Man-in-the-Middle cannot observe the handshake.
For more information about this vulnerability, see CVE-2014-4630.
How to Help Prevent the Attack
The prevention for this kind of attack is to disallow a change of server certificate when
renegotiating.
How to Help Prevent the Attack in SSL-J
SSL-J is designed to protect against this vulnerability automatically. During the
ClientKeyExchange message phase, an SSL_AD_BAD_CERTIFICATE fatal alert
is generated if the server certificate is changed during renegotiation.
No code changes are required to protect against this triple handshake vulnerability.