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

2015-08-10 Thread Salz, Rich
 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)

Do you mean me?  Or did you make a typo, and mean members rather than 
someone ?

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


[openssl-users] 1.0.2 long term support

2015-08-10 Thread Kurt Roeckx

1.0.2 long term support
===

The OpenSSL project team would like to announce that the 1.0.2
version will be supported until 2019-12-31.

Further details about the OpenSSL Release Strategy can be found here:
https://www.openssl.org/about/releasestrat.html

The OpenSSL Project Team



signature.asc
Description: Digital signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


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

2015-08-10 Thread 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

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users