TLS break

Nicolas Williams Nicolas.Williams at
Mon Nov 23 17:35:07 EST 2009

On Wed, Nov 11, 2009 at 10:57:04AM -0500, Jonathan Katz wrote:
> Anyone care to give a "layman's" explanation of the attack? The 
> explanations I have seen assume a detailed knowledge of the way TLS/SSL 
> handle re-negotiation, which is not something that is easy to come by 
> without reading the RFC. (As opposed to the main protocol, where one can 
> find textbook descriptions.)

Not to sound like a broken record, and not to plug work I've done[*],
but IMO the best tool to apply to this situation, both, to understand
the problem, produce solutions, and to analyze proposed solutions, is
"channel binding" [0].

Channel binding should be considered whenever one combines two (or more)
two-peer end-to-end security protocols.

In this case two instances of the same protocol are combined, with an
outer/old TLS connection and an inner/new connection negotiated with the
protection of the outer one.  That last part, "negotiated with the
protection of the outer one" may have led people to believe that the
combination technique was safe.  However, applying channel binding as an
analysis technique would have made it clear that that technique was
vulnerable to MITM attacks.

What channel binding does not give you as an analysis technique is
exploit ideas beyond "try being an MITM".

The nice thing about channel binding is that it allows you to avoid
having to analyze the combined protocols in order to understand whether
the combination is safe.  As a design technique all you need to do is
this: a) design a cryptographically secure "name" for an estabilished
"channel" of the outer protocol, b) design a cryptographically secure
facility in the inner protocol for veryfying that the applications at
both ends observe the same outer channel, c) feed (a) to (b), and if the
two protocols are secure and (a) and (b) are secure then you'll have a
secure combination.

[*] I've written an RFC on the topic, but the idea isn't mine -- it
    goes as far back as 1992 in IETF RFCs.  I'm not promoting channel
    binding because I had anything to do with it, but because it's a
    useful technique in combining certain cryptographic protocols that I
    think should be more widely understood and applied.

[0] On the Use of Channel Bindings to Secure Channels, RFC5056.


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at

More information about the cryptography mailing list