Advanced SSL Topics - Implementing SSL/TLS Using Cryptography and PKI - page 469

GET /bank/login.cgi HTTP/1.1
Host: www.bank.com
Connection: Close
Cookie: session=12345
Notice that the session cookie, set by the server in the login response, is used
to correlate this request with the previous login and authenticate that whatever
action is taken next is done on behalf of a user whose ID is “josh.” Because the
connection is secure, the browser fi rst sends a TLS Client Hello message. The
attacker sees this and intercepts it. He then begins his own TLS connection
with www.bank.com, which accepts his connection. Once the connection is
established, he submits the following HTTP request
GET /bank/transferfunds.cgi?amount=1000000&destinationAccount=98765
x-ignore-header:
with no trailing CRLF. The attacker then allows the victim's original Client
Hello request to pass through. He intercepts each message and encrypts it using
his own active cipher state. The victim negotiates what appears to him as a
brand-new TLS connection. Meanwhile, to the bank this looks like a legitimate
renegotiation — remember that TLS renegotiation can be initiated at any time
by the client, whenever it sends a new Client Hello.
Once this negotiation is complete, the attacker cannot eavesdrop on the victim's
traffi c, but it doesn't matter — the damage has been done. The victim sends his
original request, but to the server it looks like this:
GET /bank/transferfunds.cgi?amount=1000000&destinationAccount=98765
x-ignore-header: (slight pause for renegotiation) GET /bank/login.cgi HTTP/1.1
Host: www.bank.com
Connection: Close
Cookie: session=12345
The x-ignore-header is included to trick the server into ignoring the client's
actual GET command. The cookie is correct, so the bank goes ahead and trans-
fers the money. This technique only allows the man-in-the-middle to prepend
data — but as you can see, that's enough to mount a devastating attack.
Defending Against the Renegotiation Attack
The problem here is that the server has no way of verifying that the request that
preceded the renegotiation came from the same source that actually performed
the renegotiation. A malicious attacker can intercept a client request, block it,
submit his own request — for something that only an authenticated client can
do — and then allow the client to complete the authenticated renegotiation.