[TLS] TLS or HTTP issue? (was: TLS renegotiation issue)

[Nikos Mavrogiannopoulos <nmav at gnutls.org>]

Eric Rescorla wrote:
> TLS WG members will want to check out this announcement of a
> new attack on the TLS renegotiation logic. See here:
> 
> http://www.extendedsubset.com/
> 
> The high-level summary is that the attacker negotiates TLS with the
> server and then subsequently proxies the client's negotiation *over*
> that channel. This allows the attacker to inject arbitrary content of
> their choice in front of data sent from the TLS client to the TLS
> server. This data will be treated by the server as if it came from the
> client. Once the new handshake has finished, the attacker can't
> do anything else useful.

 I'll become a bit pedantic and note here that this isn't really a TLS
issue. We have an initial server-authenticated only session and some
renegotiation of parameters over it to authenticate the client. However
TLS doesn't guarantee[0] that if the renegotiation is successful
authenticating the client, then the data from the initial session were
also by the same authenticated client.
 Think for example a session that it is anonymous (DH). Why one should
assume that commands over the anonymous connection are to be trusted if
a successful renegotiation follows?

So for me the issue is on HTTP's usage of the TLS protocol
renegotiation. After a TLS renegotiation for authentication the previous
command cache should have been cleared and reissued after negotiation.

I like the fix in TLS though. As I understand it is a way for the
clients and servers to keep some state between negotiations, which is a
good thing and actually seems to give the guarantee above.


regards,
Nikos

[0]. or is it mentioned somewhere I didn't notice?