On Sat, Aug 01, 2015 at 04:23:54PM +0200, Kurt Roeckx wrote: > > The old team would have gone out of their way to make sure > > the standard OpenSSL code would generate backward compatible > > hello records by default > > So it's my understanding that you suggest the default OpenSSL > client should: > > - Only support SSLv2, SSLv3 and TLS1.0 because things break when > we we try to talk to some sites indicating we support TLS 1.1 > and/or 1.2? Maybe we should even disable TLS 1.0 and SSLv3? > - Don't send any TLS extentions, since some sites don't support > it? > - Don't send any cipher strings with the first byte different from > 0 because some implemantation don't look at the first byte and > might then select a cipher we didn't announce? > - Enable all the work arounds for broken implementations again, > even when they can be exploited? > - Give RC4 such a priority by default that it's in the list before > much stronger ciphers because that's the only cipher from our > default list that works with some implementations, even when the > RFCs say we should disable RC4 by default? > > I guess we should just stop trying to improve in general. There is a pragmatic "middle-ground" that I think we're actually largely successful at achieving. Nobody will adopt all the cool new stuff if it significantly breaks interoperability with the old. So we have, for example, the padding extension for the client HELLO to work around F5 problems, and various bug work-arounds are still enabled via SSL_OP_ALL. Neither full-steam ahead, nor maintaining compatibility crutches forever is the right answer. It turns out that the Windows 2003 stack issue has not received much attention outside the Postfix user community (Postfix enables anon_DH and anon_ECDH ciphers and so ran into this sooner than other applications). But even with Postfix, the impact has been rather modest, these systems are not that common. Should I have a made a greater fuss about ensuring interop with Windows 2003, I don't know. I certainly mentioned it on various non-Postfix lists at various times. Various members of the "old team" were on some of those lists. Perhaps more effort should have been made to accommodate such systems for a longer time, by enabling fewer new ciphers by default, but that's not what happened, and there have not been very many problem reports. All this I think points to a reasonably responsible process, with a largely reasonable outcome. If a consensus emerges around a "concise" cipherlist (note that to get there I had to disable DSS, which might not be popular in .gov circles, where perhaps it was actually used), I'd support that, but it is not clear to me that there's a compelling case to make this a default configuration. -- Viktor.
