gnutls-devel
[Top][All Lists]
Advanced

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

Re: Draft release notes for 2.10.0


From: Simon Josefsson
Subject: Re: Draft release notes for 2.10.0
Date: Fri, 30 Apr 2010 16:53:07 +0200
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)

Tomas Hoger <address@hidden> writes:

> On Thu, 29 Apr 2010 09:41:03 +0200 Simon Josefsson wrote:
>
>> proper client attempts to contact the server, the attacker hijacks
>> that connection and uses the TLS renegotiation feature with the
>> server and splices in the client connection to the already
>> established connection between the client and server.
>
> "*attacker* and server"

Fixed, thanks.

>> However, some server implementations will (incorrectly) assume that
>> the data sent by the attacker was sent by the now authenticated
>> client.
>
> Renegotiation does not have to change client authentication status
> (either TLS or application level).  Twitter attack is one example.

I added a paragraph explaining that the paragraph is only one example,
and that other scenarios exists, see entire patch in:

http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=468b1d0d428cb36042ee4014bcac4a4513d1e74a

>> However, by default GnuTLS client and servers will not refuse
>> renegotiation attempts when the extension has not been negotiated, as
>> this would break backwards compatibility and cause too much
>> operational problems.  We will likely reconsider these defaults in
>> the future.
>
> If these defaults change (discussion in the other thread), you may
> wish to extend this to cover different impact of allowing initial / re-
> negotiation on clients and servers.

I agree -- and I believe we'll change the defaults here, so this aspect
needs to be revisited.

>> To modify the default behaviour, we have introduced three new priority
>
> Following paragraph describes 4, even though one is special.

Fixed too.

Thanks,
Simon




reply via email to

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