[openssl-users] [openssl-1.0.2d] default SSL handshake fails

[Jakob Bohm]

On 01/08/2015 08:00, Viktor Dukhovni wrote:
>> 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?

I have taken my time to answer this, as it deserved
some careful thinking.

The problem over the past year or so is not as much
that any old maintainers have left, as that the entire
project seems to have given off a "vibe" of being
"under new management".

Specifically, a number of decisions have the feel of
a project that has been co-opted or taken over by
someone eager to make sweeping changes for little
apparent reason, someone with lots of idle lawyers
on hand, like "Microsoft, various corporate partners,
the CII, and/or the SFLC" (using a list from the latest
public blog post), yet seemingly unaware of the dangers
of combining a UK jurisdiction with phrases such as
"the public benefit" in an area of technology which
has historically been subject to much UK government
interference over the past 70 years.

I also see a tendency to throw historical decisions
overboard with little effort to understand why such
decisions might actually be or have been good
decisions.  For instance, in the penultimate blog
post, most of the things removed under "dynamic
memory cleanup" actually serve real purposes:
protective parameter validation against future code
bugs, thus by definition not counted in automated
"coverage tools" (NULL checking before free),
making malloc calls compile with C++ compilers
(casting the return value of malloc to specific
pointer type), forcing compiler errors if variable
types change (that same cast!).


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded