[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: safe renegotiation: confirming consensus
From: |
Daniel Kahn Gillmor |
Subject: |
Re: safe renegotiation: confirming consensus |
Date: |
Mon, 03 May 2010 12:46:05 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100411 Icedove/3.0.4 |
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:
https://wiki.mozilla.org/Security:Renegotiation#Control
That said, i don't currently see that this approach confers much of a
security advantage.
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?
--dkg
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.
signature.asc
Description: OpenPGP digital signature