[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TLS Renegotiation problem

From: Simon Josefsson
Subject: Re: TLS Renegotiation problem
Date: Tue, 10 Nov 2009 08:08:49 +0100
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)

Daniel Kahn Gillmor <address@hidden> 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.


> 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,
                             "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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]