Re: [TLS] simplistic renego protection

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

Ben Laurie wrote:
> On Fri, Nov 20, 2009 at 10:41 AM, David-Sarah Hopwood <
> [e-mail]> wrote:
> 
>> Stefan Santesson wrote:
>>> On 09-11-20 5:24 AM, "Michael D'Errico" <[e-mail]> wrote:
>>>
>>>> Some servers apparently cannot function without renegotiation.
>>>> They will need to continue providing service to unpatched
>>>> clients for some amount of time and thus remain vulnerable.
>>> I fully agree,
>>>
>>> However, just because a server accepts renegotiation with an unpatched
>>> client, does not necessarily mean that the service provided over TLS is
>>> vulnerable.
>>>
>>> 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 depends on those layers. If, for example, clients and servers simply
> numbered their requests/responses, they would be immune to the attack.

That's not sufficient. They'd also have to make sure that renegotiation
boundaries coincide with request/response boundaries. That requires that
the app be notified by the TLS library precisely when a renegotiation
occurs, and that individual reads and writes cannot extend across a
renegotiation boundary. This contradicts the assumption that I stated
explicitly above: "if the TLS library merges renegotiated sessions".
It's also rather prone to application error even in cases where it would
theoretically work.

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