# TLS Triple Handshake Attack

TLS Triple Handshake: MITM injects session resumption between two full handshakes to bypass RFC5746 renegotiation binding, authenticating as victim client to server.

- Payout: hidden
- Severity: high
- Program: Internet Bug Bounty
- Found by: prosecco-inria
- Disclosed: 2014-03-03
- Write-up quality: 9/10
- Original: https://hackerone.com/reports/7277
- Library page: https://bugbountylibrary.com/r/h1%3A7277
- Tags: area:devices domain:network impact:integrity impact:internal-access kind:bounty platform:hackerone sev:high technique:chained technique:source-review vuln:auth-bypass vuln:crypto

**Target:** TLS handshake / session resumption / renegotiation with client certificates
**Root cause:** The TLS master secret is not bound to enough elements of the session; injecting an abbreviated handshake between two full handshakes makes the RI extensions on both sides identical, so the renegotiation countermeasure cannot distinguish the MITM's connection from the victim's.
**Steps:**
1. C connects to M and M connects to S, both RSA full handshakes; M forwards client hellos, receives encrypted PMS from C and reencrypts it toward S, so both sessions share master secret, nonces and session id.
2. C resumes its session with M on a new connection and M resumes with S; M forwards abbreviated handshake messages unchanged, RI extensions are empty on both, so both connections share record keys and handshake logs.
3. S requests renegotiation with client certificate; M relays the renegotiation unchanged between C and S; since handshake logs matched, RI extensions match and both complete with mutually-authenticated sessions.
4. Result: S's connection initially carried anonymous M data then authenticated C data, breaking RI guarantees; M can also replay its earlier messages as authenticated to C.
**How found:** Observed that RFC5746 RI extension only covers renegotiation on a single connection; hypothesized that inserting a session resumption between two full handshakes would make the handshake logs (and thus RI extensions) identical on both sides, defeating the countermeasure.
**Exploitation:** A malicious server M that a client C connects to (and that C also uses its client cert against) relays handshakes to a real server S, synchronizing sessions via injected resumption so that M authenticates as C to S and as S to C, enabling authenticated request injection on S's connection.
**Escalation:** Also breaks any application-level binding relying on the TLS master secret, tls-unique channel binding, or exported keying material, since those parameters are identical across the two connections after step 2.
**Insight:** When a protocol binds security to a transcript hash, check whether an attacker can make two distinct connections produce identical transcripts by splicing an abbreviated/resumption handshake in between; any binding derived only from the master secret (channel bindings, exporters) inherits the same flaw.