safe renegotiation in client side

[Simon Josefsson]

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

>> If I understand correctly, it doesn't
>> improve anything for the client to behave like that, it is only the
>> server that is protected by such a client.
>
> I don't think this is the case.  A client connecting to an unpatched
> server is vulnerable to their connection being used to authenticate
> another request that they are unaware of.
>
> The attack in question is a plaintext prefix injection attack: the
> attacker starts a session with the server, and then prompts a
> re-negotiation.  It hands off the re-negotiation to the actual client,
> which might then negotiate to the server thinking that it is the initial
> connection (not a re-negotiation).  If the server then uses the new
> connections credentials to act on the original (spoofed) part of the
> session, it is the *client's* credentials which have been mis-applied,
> not the server's.

Right.  But it is the server that makes the mistake of assuming that the
newly negotiated client credentials has anything to do with the earlier
request, isn't it?

To me, the renegotiation protocol flaw means that any server that uses
renegotiation MUST require support for safe-renegotiation in the client.
This is a critical security issue with the server that needs to be
addressed as quickly as possible.  I don't see any critical security
issue on the client side at all.  The only reason clients needs to be
upgraded is that without clients, servers will be unable to use
renegotiation.

> clients which "fail closed" by rejecting connections to unpatched
> servers cannot have their credentials mis-applied in this way.   (they
> also won't be able to talk to the majority of the TLS-capable hosts on
> the 'net today, unfortunately).

Right, if a client has a policy of not talking to any potentially buggy
server, this makes sense.  But I'm not sure that is useful -- servers
are potentially buggy all the time (many still only supports SSL 3.0),
but clients still wants to talk to them.

>> Thus, I think we should let
>> servers require patched clients when it makes sense, and otherwise be
>> more lenient on the client side.
>
> libnss (the mozilla tls implementation) has an interesting phased
> approach planned to deal with this situation:
>
>   https://wiki.mozilla.org/Security:Renegotiation
>
> i know gnutls doesn't expose as much in the way of a UI as NSS clients
> like firefox or thunderbird; but if there's some way to adopt a similar
> approach, i'd like to examine it.
>
> Every libgnutls-aware program can see the environment, for example.  is
> using a clearly-scoped environment variable to provide a priority string
> if none other are supplied out of the question?  Or what about
> ~/.libgnutls/config or something similar?  I'm just brainstorming here,
> feel free to explain why these are horrible proposals.

Couldn't we be lenient today, and in 2-3 years time start to reject
buggy servers by default?

>> I wish there was an easy way to warn the user somehow though.  Syslog a
>> message with the server hostname?  Should we add a function so that
>> applications can find out if a session is potentially insecure due to
>> this threat?  Any way to make it less specific to renegotiation issues?
>> We have other areas that users may want to be aware of too -- e.g., if
>> the connection is using a weak cipher, if the connection is not using
>> DHE, etc...  OTOH maybe this is overkill.  Power-users can use
>> gnutls-cli to find out manually, and other users are probably fine with
>> a lenient default anyway.
>
> gnutls-cli can find out manually for a different connection -- it won't
> let you inspect an active connection, will it?

Right, I'm just thinking of how to identify buggy/working servers.

> i agree that configurable reporting would be useful, though (and i like
> your assessment of the other concerns we might want to permit but warn
> about).  Seems like a generic interface would be a way for library users
> register a callback that reports "warnings about your connection", along
> with an enumerated list (and maybe localized strings describing the
> problems).
>
> I like that idea, but if we can't convince application developers to let
> end users pass in a priority string, it seems unlikely that we'd get
> them to register such a callback, let alone report the warnings to their
> users in a sane way :/

I agree, so it seems like a waste of time right now. :-(

/Simon