Re: [TLS] simplistic renego protection

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

Ben Laurie wrote:
> On Sat, Nov 21, 2009 at 2:18 PM, David-Sarah Hopwood <
> [e-mail]> wrote:
> 
>> 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.
> 
> I don't believe your argument. For example, if each byte were numbered, then
> the application would not care one whit about boundaries (other than
> reconnections, which it manages anyway).

Numbering each byte is not what you suggested above. You haven't given
enough detail to tell whether this could work, but if for the sake of
argument it could, it would require incompatible changes to the application
protocol. Therefore, it's not an argument that justifies the original
point by Stefan Santesson above, about servers that accept renegotiations
with unpatched clients not necessarily being vulnerable. In practice, such
servers will be vulnerable for existing protocols.

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