TLS Renegotiation problem

[Simon Josefsson]

Tomas Hoger <thoger at redhat.com> writes:

>> I think we now have some evidence to suggest GnuTLS needn't do anything
>> about this.  It seems any use of rehandshake with GnuTLS is
>> application-specific and then the answer is probably to fix that
>> application instead of GnuTLS.
>
> Is that meant as meant as "no change needed" or "no urgent temporary hotfix
> needed"?

Both. ;-)

The situation appears to be that 1) there is no patch against GnuTLS
that we can use as a temporary hotfix, and 2) there appears (so far) to
be no servers that use GnuTLS in a way that is vulnerable to this
problem.

There _could_ be servers that use GnuTLS which were vulnerable.  For
these applications, the simplest short-term solution appears to be to
remove/disable the TLS renegotiation code.  That would be an urgent
problem that needs to be addressed quickly, if there actually are
deployed instances of that situation.

If a majority of servers that used GnuTLS were vulnerable to this
problem, I think we'd have to consider patching GnuTLS instead of
recommending patching application.  Compare when we changed X.509 path
validation in GnuTLS to check expiry/activation times: it was not a
GnuTLS problem but it affected so many applications and it made more
sense to fix it in GnuTLS than change all the applications.  Our survey
of servers using GnuTLS indicates that we are not close to being in this
situation for this problem.

Daniel suggested to add a priority string to allow admin's to disable
TLS renegotiation unconditionally without having to recompile
application/libraries.  That seems like a good idea, but there are no
instances where we known that it would improve anything.  Priority
strings is a quite new features, so the application would have to make
use of priority strings AND do renegotiation AND implement a protocol
that is vulnerable to this attack (e.g., HTTP) in order for things to
work.  That situation seems unlikely, but could happen, and then we'll
certainly implement Daniel's suggestion.

We could also release a GnuTLS that does not support TLS renegotiation
at all.  Right now, that is not known to fix anything, so I don't see
what you would gain in doing so.  But we could end up needing to do that
too.

So, in summary, given (my) current knowledge there is no need to either
patch GnuTLS or any server application using GnuTLS.

> Is the implementation of the proposed extension still the long-term
> plan, so that apps needing rehandshakes can do them safely?

Yes.

/Simon