safe renegotiation: confirming consensus
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Mon May 3 18:46:05 CEST 2010
On 05/03/2010 10:28 AM, Simon Josefsson wrote:
> Based on recent discussion, here is my perception of what I believe
> would be the best to implement. Note that this is not what is
> implemented today, so some of the priority strings below have slightly
> different meaning now.
> Client behaviour:
> Clients will talk to servers that do not support the extension by
> default, but will refuse any rehandshake attempts against those
> servers. This would cause operational problems: can we confirm that
> NSS and/or OpenSSL clients behave like this? Otherwise we probably
> shouldn't enable it.
NSS appears to be using this approach:
That said, i don't currently see that this approach confers much of a
The user is already vulnerable just by having made the initial
connection (which appears to the client as a negotiation, but might
appear to the server as a renegotiation if there was a prefix injection
that already happened).
Can anyone describe what additional threat we defend against by
declining to renegotiate with vulnerable servers?
PS i can imagine that by declining re-negotiation we might alert the
server operator (via bug reports or error logs) that they should upgrade
their TLS toolkit, but that doesn't seem like a good tradeoff to me if
it means that we force our users to lose functionality.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 892 bytes
Desc: OpenPGP digital signature
More information about the Gnutls-devel