In November 2009, the renegotiation vulnerability over SSL/TLS based protocols was published.  SSL renegotiation is a new SSL handshake over an already established SSL connection.

The attacker sits between the client and the server and applies MITM attack. The idea of the attack is as follows:

(1) The client starts a TLS handshake with the server. The attacker stops this connection and holds the handshake packets (session #1)
(2) The attacker completes a full TLS handshake with the server and sends application layer requests of his choice to the server (session #2)
(3) The attacker requests a renegotiation of the handshake process. He then forwards handshake packets of the session #1 within the encrypted session #2
(4) The client holds now an authenticated session and sends requests containing the authentication credential (i.e. cookie). The attacker gets this request and appends the client request  to its previous request (sent in Step 2) and forwards to the server.
(5) As a result, the final merged request consists of the attacker request and the authentication credential from the authenticated client.

A sample merged Request seems as follows: The request in red is sent by the attacker and the request in green is sent by the client.

GET /transact.php?value=evil HTTP/1.0
X-Ignore: Get / HTTP/1.1
Cookie: [...]

Practical attacks for different protocols and scenarios are explained in this paper.

Finally, if you need to test if your system is vulnerable to this attack,  you can try this:


Openssl s_client –connect yourserver.com:443
GET / HTTP/1.0 Host:yourserver.com
R (Triggers renegotiation – if this works, the server accepts renegotiations within an existing TLS session Req. #1)
CRLF
<server responds with content> (server merged both sessions Req. #2)