safe renegotiation in client side
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Mon Mar 15 22:30:29 CET 2010
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:
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
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 :/
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 891 bytes
Desc: OpenPGP digital signature
More information about the Gnutls-devel