TLS Renegotiation problem

[Simon Josefsson]

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> On 11/09/2009 10:19 AM, Simon Josefsson wrote:
>> It is important to understand that you are not vulnerable unless you use
>> renegotiation, which is not typical.  If you use renegotiation, perhaps
>> to request client certificates in a web server, the simplest "fix" is to
>> disable any use of renegotiation.
>
> My understanding is that the published attacks are undetectable from the
> client-side without the use of the newly-proposed extension.

Yes.

> So barring that extension, it seems that that the protective
> workaround you describe (disabling renegotiation) needs to be done on
> the server side.
>
> Is there a way that this can be done generically with GnuTLS (e.g. a
> priority string, which could conceivably be passed into gnutls by an
> administrator without needing a rebuild), or should the server simply
> avoid calling gnutls_handshake() more than once per session?

In GnuTLS, rehandshaking needs to be done explicitly by servers when
they get the GNUTLS_E_REHANDSHAKE error back from gnutls_record_recv.
If servers don't call gnutls_handshake when that happens, there is no
problem.  So people can check their applications if they are vulnerable
to this problem.

For example, the mod_gnutls Apache plugin does not support renegotiation
so there is no problem with it (this was the main case that I were
concerned with):

            if (rc == GNUTLS_E_REHANDSHAKE) {
                /* A client has asked for a new Hankshake. Currently, we don't do it */
                ap_log_error(APLOG_MARK, APLOG_INFO, ctxt->input_rc,
                             ctxt->c->base_server,
                             "GnuTLS: Error reading data. Client Requested a New Handshake."
                             " (%d) '%s'", rc, gnutls_strerror(rc));
            }

Possibly we could indeed have a new mode where GnuTLS refuses to do
renegotiation based on a priority string.

/Simon