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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Help-gnutls mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnutls
