[openssl-1.0.2d] default SSL handshake fails

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux