[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: safe renegotiation in client side
From: |
Simon Josefsson |
Subject: |
Re: safe renegotiation in client side |
Date: |
Thu, 29 Apr 2010 10:10:07 +0200 |
User-agent: |
Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) |
Tomas Mraz <address@hidden> writes:
> On Mon, 2010-03-15 at 21:46 +0100, Nikos Mavrogiannopoulos wrote:
>> As you may have noticed there was a big fuss lately about a bug in the
>> TLS protocol that could cause a client to connect to the wrong server
>> via a renegotiation. There is a fix to the protocol that is
>> unfortunately incompatible with previous versions (if security is
>> required). Thus a gnutls client implementing the fix cannot connect to
>> any non-patched server[0]. To achieve compatibility one has to to
>> explicitly allow unsafe renegotiation with a priority string. This is
>> not always possible since gnutls might be used unintentionally by a
>> program via another library.
>>
>> With some trials in my system I noticed that the current behavior causes
>> denial of service and a simple user might not even have control over the
>> priority string for gnutls.
>>
>> Given your experiences (as system packager, user, implementor or so),
>> what do you think is the adoption of priority strings in programs? Given
>> a program that uses gnutls is it easy to set a string with the
>> algorithms etc. needed for the negotiation?
>
> The OpenSSL upstream decided to allow the client to talk to the
> unpatched servers by default. Of course it means that if the client
> talks to such server it is vulnerable to the attack. They've also added
> a function call so an application can query whether the connection is
> protected by the safe renegotiation or not.
GnuTLS will behave the same.
> I, as maintainer of OpenSSL and gnutls packages in Fedora and Red Hat
> Enterprise Linux, decided when backporting the safe renegotiation
> patches to the old gnutls packages in released distributions, that the
> client has to be tolerant to missing safe renegotiation support on
> connected servers for now and so I have removed the strict client side
> check from the backported patches. If the adoption of the safe
> renegotiation extension gets better, we will release updated packages
> which will contain the strict client side check.
What is your opinion on whether servers should refuse renegotiation
attempts from clients that doesn't support the extension?
/Simon
- Re: safe renegotiation in client side,
Simon Josefsson <=