​

 
legal contact rss
 

renegotiation attack

SSL renegotiation is helpful when the routine SSL session is already established and the client authentication has to take place. For example, say you are browsing an online shopping site which uses SSL, i.e., HTTPS. Initially, you browse through the site anonymously, add items to the cart, etc. But when you decide to purchase you will be asked to log in to the site, so now the SSL connection needs to be adjusted to allow the authentication. Whatever information is gathered prior to this authentication (e.g., items added to the cart) has to be maintained even after the authentication. So the new SSL session that has to be established uses the already existing connection. Note that renegotiation can be requested either by the client or by the server at any time. For the client to request renegotiation the client sends a “Client Hello” message in the already-established encrypted channel and the server responds with a “Server Hello” and then the negotiation follows the normal handshake process. The server can initiate the renegotiation by sending the client a “Hello Request” message. When the client receives the request, the client sends the “Client Hello” message and the handshake process takes place. This explains the basic SSL renegotiation process.

http://resources.infosecinstitute.com/ssl-attacks/

Danger:

Using the renegotiation attack, an attacker can inject commands into an HTTPS session, downgrade a HTTPS connection to a HTTP connection, inject custom responses, perform denial of service, etc. That explains to some extent how serious the problem is. It is easier to understand how the attack is accomplished through the following example.

  1. Assume that a client wants to connect to a online banking site. He initiates the routine TLS handshake process
  2. The client blocks the request and holds the packets.
  3. The attacker initiates a new session and completes a full TLS handshake.
  4. The attacker sends a GET request (asking to send money to his account) to the bank application.
  5. Server asks for renegotiation.
  6. The TLS handshake initiated at step 1 and blocked by the attacker will now be forwarded to the server, which a new TLS handshake over the previously established encrypted TLS session 2. So the client now is authenticated and has a valid cookie.
  7. Due to this renegotiation, the server now assumes that the previously sent request in step 4 was actually sent by the client. Hence the request which goes to the server is as follows; it will be interpreted by the server as a legitimate request and then executed.

GET /bank/sendmoney.asp?acct=attacker&amount=100000

Ignore the rest: GET /ebanking

Cookie: validcookie

Fix:

One way to fix the renegotiation vulnerability for SSLv3 is to completely disable renegotiation on the server side. As a permanent fix for the vulnerability, a renegotiation indication extension was proposed for TLS that will require the client and server to include and verify information about previous handshakes in any renegotiation handshakes.

Risk: High

Aditional reading: http://www.porcupine.org/postfix-mirror/smtp-renegotiate.pdf