[openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Jakob Bohm]

But they care very much if Cisco AnyConnect (or any other
OpenSSL using program they may need) stops working or
becomes insecure because the OpenSSL team is breaking
stuff just because it is not needed in their own handful
of example uses.

And while ordinary people may not know or care, they will
be deeply affected by the increase in undiscovered
vulnerabilities if the white hat research community stops
supporting OpenSSL by researching its code more deeply
than any other crypto library.  It is already bad enough
that no code review made before the giant reformat
provides much insight into the current code, because it
is virtually impossible to independently review the mega-
patch that mixed reformatting and actual code changes.

Fundamentally, appealing to what "ordinary users" care
about in the way you just did is an appeal to stupidity.
Ordinary users don't know how the innards of OpenSSL
affect their lives, as was so clearly seen when the first
a lot of them heard about OpenSSL was Heartbleed and the
resulting "gut reactions" was to say that OpenSSL must be
a fundamentally bad thing (spurred along by mass media
describing Heartbleed as a "virus").  Or think about all
the people confusing the Android stagefreight multimedia
library with the recently discovered vulnerabilities in
that same library.

Note that I am not saying ordinary users are stupid,
they just don't know a lot of things about our
profession, as they don't know much about each others
professions either.  This is the fundamental principle
of specialization ever since the concept of professions
was invented millennia ago.

On 23/11/2015 17:05, Short, Todd wrote:
> I suspect that most “users” of OpenSSL are doing it indirectly through 
> other applications that use TLS (or crypto) functionality. Example: 
> the Cisco AnyConnect client is reportedly one of the most installed 
> pieces of software regardless of platform; it uses OpenSSL for TLS.
>
> Taking those indirect users into account, they don’t care about the 
> research or advanced uses of OpenSSL; they just want to connect 
> securely to their corporate network.
>
>> On Nov 20, 2015, at 9:09 PM, Peter Waltenberg <pwalten at au1.ibm.com 
>> <mailto:pwalten at au1.ibm.com>> wrote:
>>
>> Quite reasonable except.
>>
>> I'm not sure you have majority and minority the right way around. My 
>> guess would be that the majority of OpenSSL users are libcrypto. 
>> consumers rather than SSL/TLS consumers.
>>
>> A point several of us have been trying to get through for some time.
>>
>> -----"openssl-dev" <openssl-dev-bounces at openssl.org 
>> <mailto:openssl-dev-bounces at openssl.org>> wrote: -----
>> To: "openssl-dev at openssl.org <mailto:openssl-dev at openssl.org>" 
>> <openssl-dev at openssl.org <mailto:openssl-dev at openssl.org>>
>> From: "Short, Todd"
>> Sent by: "openssl-dev"
>> Date: 11/21/2015 08:28AM
>> Cc: "openssl-users at openssl.org <mailto:openssl-users at openssl.org>" 
>> <openssl-users at openssl.org <mailto:openssl-users at openssl.org>>
>> Subject: Re: [openssl-dev] [openssl-users] Removing obsolete crypto 
>> from OpenSSL 1.1 - seeking feedback
>>
>> While I am all for simplicity, I also think that removing 
>> functionality is a “bad idea”.
>>
>> To reduce the support burden, deprecate the ciphers:
>> 1. Under support, indicate that these ciphers will no longer receive 
>> fixes.
>> 2. Remove any assembly implementations
>> 3. Disable them by default.
>>
>> I suggest following the 80/20 rule (sometimes the 95/5 rule):
>>
>> Those “who care” (the minority) about the ciphers can re-enable them 
>> and rebuild the library.
>> Those “who don’t care” (the majority) about the ciphers, should get 
>> the functionality that most people care about, basically SSL/TLS 
>> connectivity.
>>
>>> On Nov 18, 2015, at 1:52 PM, Blumenthal, Uri - 0553 - MITLL 
>>> <uri at ll.mit.edu <mailto:uri at ll.mit.edu>> wrote:
>>>
>>> On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk"
>>> <openssl-dev-bounces at openssl.org 
>>> <mailto:openssl-dev-bounces at openssl.org> on behalf of 
>>> bkaduk at akamai.com <mailto:bkaduk at akamai.com>> wrote:
>>>
>>>> On 11/18/2015 07:05 AM, Hubert Kario wrote:
>>>>> So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to
>>>>> support
>>>>> both relatively modern TLS with user certificates, preferably the
>>>>> newest
>>>>> cryptosystems and hashes as well as the oldest ones that were
>>>>> standardised and used.
>>>>>
>>>>> That means that old algorithms MUST remain in OpenSSL as supported
>>>>> functionality. It may require linking to a specific library to 
>>>>> make the
>>>>> EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed
>>>>> from it completely, definitely not before at least 50 years _after_
>>>>> they
>>>>> became obsolete and broken.
>>>>
>>>> There seems to be a logical leap between these two paragraphs.  Why is
>>>> it necessary that OpenSSL be the only cryptographic library used by
>>>> CAdES-A/etc. implementations?
>>>
>>> Because it used to be the only real game in town, and *people learned to
>>> rely upon it*.
>>>
>>>> Is it in fact even necessary that only a
>>>> single version of a single cryptographic library be used for such
>>>> software?
>>>
>>> No, of course not. But after letting people depend on this “single
>>> cryptographic library” for many years, telling them “too bad” isn’t very
>>> nice.
>>>
>>>> While OpenSSL may try to be a general-purpose crypto library,
>>>> when a software has stringent or unusual crypto requirements, it seems
>>>> reasonable that such a software may need to involve unusual
>>>> implementations.
>>>
>>> The requirements did not change. What changed was the maintainers
>>> expressing their desire to stop supporting some of them.
>>>
>>>> I do not believe that OpenSSL has promised anywhere that it will 
>>>> support
>>>> this sort of use case.
>>>
>>> Implicitly, by providing that kind of service for so long. And 
>>> explicitly,
>>> as pointed out by Hubert:
>>>
>>> From the main web page of project:
>>>
>>> The OpenSSL Project is a collaborative effort to develop a robust,
>>> commercial-grade, *full-featured*, and Open Source toolkit
>>> implementing the Transport Layer Security (TLS) and Secure Sockets
>>> Layer (SSL) protocols as well as a full-strength *general purpose*
>>> *cryptography library* .
>>>

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://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