On Sat, Aug 01, 2015 at 06:56:16AM +0200, Jakob Bohm wrote:
> >Or configure a cipherlist more compatible with a long obsolete and
> >no longer supported Windows 2003 TLS stack.
Note, I am suggesting compatibility. Yes while the obsolescence
is long-standing, I was aware that the support status changed just
recently. The problem with 3DES (for Exchange) is known since
2007, but the fix was never made mainstream, you had to request an
obscure Hotfix (no longer available).
> The Windows 2003 TLS stack became unsupported for most
> (but /not all/) users less than 20 days ago. Treating
> it as marginal and not as something that any core
> networking library needs to be compatible (even *tested*
> with) out of the box is another symptom of the useless
> attitudes that permeate the new OpenSSL leadership.
You should apologize, I resent that remark. Behind the scenes I
am working to ensure that we maintain reasonable compatibility with
that stack while it still exists in the field, and have helped many
users craft sensible work-arounds for the bugs in that platform.
It is not so easy to work around the rather severe limitations of
Schannel in Windows 2003. OpenSSL would have to by default disable
many of the new ciphers in TLS 1.2. Are you suggesting that the
exclusions I am recommending should have been on by default? To
accommodate a relatively rare and clearly broken peer?
We could consider such an accommodation, but I think that the wiser
course of action is to document the work-around for those who need
it. This is the first report of this problem I've seen for an
application protocol other SMTP. It was however immediately
recognizable.
> The old OpenSSL project belonged to the long standing
> tradition of making sure that Internet software needs to
> work with the quirks of anything it could reasonably
> encounter on any real world network, including both the
> Internet, the US military networks (which have allegedly
> paid a boatload of money for continued Win2003 support)
> and any closed site networks that reuse Internet protocols
> for their internal operations.
You seem to be pining for the project that lacked any resources to
pay attention to documentation or code quality. I think on the
whole more sensible trade-offs are being made now. And compatibility
is still important.
> It would have been a serious brown bag moment for the old
> maintainers to discover this in a release made that close
> to (if not even overlapping) the vendor support period for
> such a widely deployed system. There is a lot of utility
> software which is linked to OpenSSL libraries with very
> little user configurability and which is simply expected
> to "just work" when transferring data off a (not so) old
> Windows computer.
Who are these "old maintainers" who aren't around any more?
> 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, e.g. by ensuring that the
> strongest enabled Win 5.x compatible cipher was within the
> first 64 ciphers if that is indeed the technical solution.
The technical solution is correct, and can be deployed by users
who need it. By default radical trimming of the cipherlist in new
OpenSSL releases to accommodate a rather obsolete and already
relatively rare platform is likely not the right call. Perhaps
some of that "old team" you pine for might speak up as to what
they would like to see done.
Keep in mind that users who want to keep running legacy servers,
can also keep running legacy clients, they don't need to uprade to
anything beyond 1.0.1, that's still supported, and interoperates
with Schannel from 2003 by default.
$ for r in *; do echo "=== $r ==="; $r/bin/openssl ciphers -v 'DEFAULT:!PSK:!SRP' | grep -n '^RC4-SHA'; done
=== OpenSSL_0_9_8 ===
11:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
=== OpenSSL_1_0_0 ===
29:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
=== OpenSSL_1_0_1 ===
57:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
=== OpenSSL_1_0_2 ===
75:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
=== OpenSSL_master ===
93:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
[ The reason I'm excluding PSK and SRP is that IIRC the client only
actually includes these in the HELLO cipher list when an appropriate
password callback is enabled). ]
> OpenSSL is supposed to make sure that practical tools such
> as wget, curl, fetchmail etc. etc. can talk to almost any
> old SSL/TLS implementation that might be found in a dusty
> basement or on an old backup tape somewhere. Talking to an
> old Netscape Navigator 3.x or a clunky old printer should
> have a high chance of working, while talking to anything
> popular that was up to date with official security updates
> less than 2 years ago (let alone a month) is a simple must.
Yes, open source projects rightly pay more attention to interoperability
than vendors do. Microsoft's own email stack at outlook.com hangs
up on TLS email connections from Windows 2003 Schannel. They don't
support RC4 at all.
However at some point it is time to move on. I am not strongly
opposed to trimming off more of the cruft, we just need to lose 9
ciphers to squeak by with 1.0.2. It's just that this problem though
well known to me, has not been widely reported in contexts outside
of email. The team may decide to make some accommodation, but
frankly posts like the above, that are whining about past glory,
are not particularly motivating.
Would you like to see my work-around exclusions in the DEFAULT
cipherlist?
$ for r in *; do echo "=== $r ==="; $r/bin/openssl ciphers -v 'DEFAULT:!PSK:!SRP:!kDH:!kECDH:!IDEA:!RC2:!RC5:!MD5:' | grep -n '^RC4-SHA';
done
=== OpenSSL_0_9_8 ===
10:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
=== OpenSSL_1_0_0 ===
22:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
=== OpenSSL_1_0_1 ===
42:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
=== OpenSSL_1_0_2 ===
42:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
=== OpenSSL_master ===
52:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
That might be good enough, until some ChaCha20 ciphers appear, and
perhaps CCM, I can't promise there'll be fewer than 20 new ciphers
in total. At some point soon, even the above band-aid will not be
flexible enough to provide both all the modern ciphers we want
(that will actually be used) and still keep RC4-SHA around.
The simplest work-around is to explicitly disable TLS 1.2 and higher
when communicating with a known obsolete peer, it will only do TLS
1.0 anyway.
--
Viktor.
