Re: [TLS] simplistic renego protection

[David-Sarah Hopwood <[e-mail]>]

Stefan Santesson wrote:
> On 09-11-20 7:41 PM, "David-Sarah Hopwood" <[e-mail]>
> wrote:
> 
>>> One example is if authentication is performed with proper channel binding in
>>> a layer above TLS and the service is provided under that security context.
>>
>> I'm skeptical. How can "proper channel binding" be done correctly in a
>> layer above TLS, if the TLS library merges renegotiated sessions?
>> Since the session merging will result in the client and server's state
>> at the higher layer(s) being out of sync, nothing can be assumed about
>> the correct functioning of those layers.
> 
> The problem occurs on the clients initial handshake, being done in the
> clear, while the MITM is feeding this into a renegotiation with the server.
> 
> As this attack has been described, once the client and server has concluded
> an end-to-end handshake, the window for the attacker to do bad stuff is
> closed. All renegotiations are safe from this point on.

That's an oversimplification.

The attacker is able to add a prefix to the server's view of the session.
This changes the server's state from what it would have been on an
initial connection. How far the attacker's influence on the server's
state extends into that session, is dependent on the application protocol.

> The very act of channel binding, binds authentication of the client to
> unique properties of the TLS channel. Thus,  successful channel binding
> ensures that the client has concluded its first handshake (or it would not
> have anything to bind to). It also ensures that the TLS channel is carried
> end-to-end (or else channel binding would fail).

This is assuming away the problem. I said:

# How can "proper channel binding" be done correctly in a layer above
# TLS, if the TLS library merges renegotiated sessions?

The attack has already disrupted the functioning of the layer above TLS.
If any channel binding is done *at that layer* (or above), without
knowledge of the TLS renegotiation boundaries and taking specific account
of the vulnerability in TLS, then it can't be assumed to be reliable.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com