safe renegotiation in client side

[Daniel Kahn Gillmor]

On 03/15/2010 05:00 PM, Simon Josefsson wrote:
> I believe it would be painful to release a GnuTLS client that refused to
> talk to non-patched servers.

I agree that it would be painful.

> 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.

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).

> 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.

> 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?

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 :/

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 891 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20100315/e62464cb/attachment.pgp>