Tomas Hoger <[email protected]> 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 _______________________________________________ Help-gnutls mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnutls
