SSL Renegotiation vulnerability:

Renegotiation is to negotiate new terms to replace old ones.

This occurs because server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data.

The vulnerability involves a flaw in renegotiation and allows man-in-the-middle attackers to surreptitiously introduce text at the beginning of an SSL session.

Renegotiation allows one part of an encrypted connection to be controlled by another.

Step by step process for renegotiation:

1. Client starts TLS hand shake with the server, the attacker who is in the middle does not forward this hand shake packets. Let us consider this as session@1. Thus ot resemblance MITM attack.

2. The attacker negotiates a new session and performs a complete TLS exchange. Let us consider this as session@2.

3. The attacker sends application level commands over the previously established TLS session.

4. The attacker requests a renegotiation of the handshake process. Renegotiation is to negotiate new terms to replace old ones. Renegotiation may be activated due to different cipher requirements on different resources.

5. He then forwards handshake packets of the session @1 within the encrypted session @2.

6. The TLS handshake started i.e session@1 hold back by the attacker, is now being let to the server which performs a new TLS Handshake over the previously established encrypted TLS session @2.

7. 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 and forwards to the server.

8. Finally merged request consists of the attacker request and the authentication credential from the authenticated client.

Authentication Gap in SSL Renegotiation:

Authentication gap in SSL is due to renegotiation during the negotiation process at which an attacker joins heterogeneous connections in a completely standards-compliant way. Web servers will combine the data they receive prior to renegotiation with the data they receive after renegotiation.

GET attacks are essentially trivial to execute. An application that only makes changes in response to POST requests will probably not be vulnerable.

Affected Versions:

SSL version 3.0 and newer version.

TLS version 1.0 and newer version.

Resolution:

1. Disabling renegotiation:

This cannot be configured easily, but the majority of web sites do not use renegotiation so disabling it won't be a problem.

2. Using a firewall :

To monitor the contents of all request headers to spot what seems like an embedded HTTP request. Good thing is that embedded request line will not be obfuscated, making it easier to detect.

Example:

GET /path/resource.asp HTTP/1.0------à attackers
Header: GET /index.asp HTTP/1.0
Cookie: 123455678796_jjoivcdf_@Dss----> clients

Scenario:

              sess1                                 sess2

  TLS client <--->  rogue TLS server (doing MITM)  <--->  victim MS IIS

Impacts:

This vulnerability is used to theft the credentials.

This is also useful to perform CSRF attack.