Re: [TLS] simplistic renego protection

[Martin Rex <[e-mail]>]

Stefan Santesson wrote:
> 
> What I claim is that it is possible to design an application that
> use channel binding to keep itself safe from this attack.
> All it needs to do is to make sure that it's state is reset
> after completed channel binding.
> 
> The fact that it is possible to be safe despite this vulnerability is an
> argument that lenient servers should be supported in the solution.
> 
> If I analyze my application and determine that it is safe from the attack,
> then I could just allow gradual upgrades and stay lenient.

If it just was that easy.

In addition to the TLS renegotiation vulnerability there may
be unexpected consequences of the architecture of the API
that is used between the TLS implementation and the application.


The particular problem with HTTP is, that it does not authenticate
the request as first thing in the protocol when Cookie-based
or basic authentication is used, which makes that particular
attack successful.

When TLS client-certs are used it may actually become _a_lot_worse_
because the TLS authentication is not tied to a specific
request, but instead is supposed to authenticate the entire channel
and all data that travels it.  Here is where HTTP 1.1
Connection: Keep-alive significantly expands an attackers options.


If no client-certs are used and the authentication is performed
inside the application data as the first thing in the request,
then this app might not be vulnerable.



I can't comment on the "application that use channel binding" though,
because I don't understand that concept yet.  If the app uses
some crypto stuff outside of regular TLS to digitally sign or
protect each request with a keyed hash based on cryptographic
properties of the TLS channel (like the finished messages),
then this could work.

But the problem that I see there is the layering.  TLS is supposed
to go directly on top of TCP.  If the application several layers
above TLS uses properties such as a finished message for
a keyed hash on individual requests, then I don't see how this
could work well in a distributed environment, where the
original TLS channel might be terminated at the perimeter of
the distributed backend system (server farm), while the
backend application runs on some backend machine far away from the
endpoint of the TLS channel.


A layering violation of that kind puts significant constraints
on the (absence of compexity of) the infrastructure where it
might be used.


-Martin