renegotiation attack

Summary

Premise

• TLS renegotiation is enabled, pre-RFC 5746
• client thinks it is talking securely to the server; server accepts renegotiation mid-session
• MITM attacker in network layer is positioned between client and server
• server does not bind pre-renegotiation data to the authenticated session

Attack

1. client initiates a TLS handshake
2. attacker intercepts and defers it
3. attacker uses client’s token to establish a TLS connection with the server
4. attacker sends arbitrary data to the server as if it came from the client
5. attacker then renegotiates the TLS session and forwards the client’s legitimate handshake
6. after renegotiation, the server sees the connection as authenticated and binds attacker-injected data with the victim’s data
7. server processes attacker’s prefix as part of the client’s request (eg. HTTP request prefix)

Attacker’s Goals

• inject commands into an authenticated TLS connection -> integrity
• override commands sent by the victim -> availability
• perform actions as the victim -> integrity

Defense

• disable renegotiation -> affects availability
  • TLS 1.3 removes renegotiation completely
• at the application layer, enforce strict message framing and authentication on every operation

Concept

TLS handshake

• protocol flaw
• unilateral authentication, client verifies the server
• assumes that the user is already authenticated, using cookies or authenticated thereafter via the application layer

TLS renegotiation

• allows client/server to initiate a new session from an existing session
• 2nd handshake to establish new session key

TLS renegotiation attack

• MITM
• impersonate the client