On Mon, 01 Jul 2013 18:22:41 -0400 Daniel Kahn Gillmor <[email protected]> wrote:
DKG> On 07/01/2013 05:50 PM, Ted Zlatanov wrote: >> We understand it's insecure. Our users have told us some servers won't >> work without it. DKG> I'd be curious to know which servers fail like this. on those servers, DKG> i'd say you'd be better off just not negotiating the any of the DHE DKG> ciphersuites at all, rather than forcing the connection to a DKG> trivially-crackable diffie-hellman exchange. Here are the user reports about buggy servers and further discussions, though in many cases they don't tell me the server name and I haven't been asking. http://lists.gnu.org/archive/html/bug-gnu-emacs/2011-07/msg00657.html http://lists.gnu.org/archive/html/bug-gnu-emacs/2012-04/msg00761.html http://thread.gmane.org/gmane.emacs.gnus.general/83413/focus=83441 On Tue, 02 Jul 2013 01:00:09 +0200 Nikos Mavrogiannopoulos <[email protected]> wrote: NM> The set_prime_bits sets the lowest acceptable threshold for a DHE prime. NM> That is the actual security level. That unfortunately it is not NM> negotiated in TLS, and thus the client can only drop the connection if NM> the server goes lower than that threshold. A way to overcome that issue NM> is instead of lowering the threshold, to retry a connection without DHE NM> as Daniel mentioned. (Assume we're upgrading Emacs to use the latest GnuTLS.) I think negotiating the connection twice is unacceptable for performance. We have to find a way to do it in one attempt, even if the user has to configure something about the exceptional servers. Can we always try ECDHE and only do DHE if the user tells us so? >> - how can we detect a server that demands 256 and renegotiate only for >> those servers? NM> You cannot. The way TLS is designed, you only get an error at the NM> handshake. >> We've been considering requiring GnuTLS 3.x but due to the platforms we >> support in Emacs, that's not a simple decision. Can you explain the >> above questions and how they are different with ECDHE? We plan to move >> to 3.x fairly soon in any case, but knowing this will make my life easier. NM> In ECDHE the curve (which is effectively the security level) is NM> negotiated and thus has not the problems of DHE. >> Will legacy servers (of which there are many, all critical to our users >> apparently) work with ECDHE? NM> Unfortunately, I cannot know that. If they are very old servers most NM> probably wouldn't support elliptic curves. Well, there's always collateral damage. We can tell our users "This server is very old so it can't work by default. You can set this special workaround but only for a specific host name." So I think it's enough to detect this case, and in Emacs-land we can even auto-configure so it only happens once. Can we, then, have the following sequence: - always connect with ECDHE, no DHE at all - if ECDHE doesn't work, tell the user to configure some-special-variable for the target host to use DHE. This will also let the user set the DHE min prime bits. This code path does the dh_set_prime_bits in the priority string. If so, could you tell me how to do the two steps? I can't find examples of this fallback in the manual in the repo or online, unfortunately. (It would have been nice if the priority string could have the dh_set_prime_bits control in it from the beginning. I suggested packing as much as possible in the priority string in the past, and still think it's a good idea, essentially giving users a DSL to control GnuTLS connection parameters. Then the problem is reduced to keeping a special priority string per host name, which is much more manageable for our users.) Ted _______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
