[openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX

[Steffen Nurpmeso]

"Salz, Rich via RT" <rt at openssl.org> wrote:
 |> Personally i am willing to put enough trust in the OpenSSL team *even
 |> insofar* as i now do 'set ssl-protocol="ALL,-VULNERABLE"'
 |> and leave the task of deciding what is VULNERABLE up to you.
 |
 |That is not a responsibility we want.  No how, no way.  It \
 |is enough to be responsible for the code.
 |
 |There are better alternatives, including bettercrypto.org \
 |and another proposal from RedHat to have site/distro-specific 'profiles' 

Sorry but i simply fail to understand your point of view.
I'm fine would OLDEST/NEWEST/VULNERABLE instead end up as
MIN/MAX/SECURE (booooring, but.. understandable).

But i really missed (and still miss) the possibility on the
_OP_NO_ level, and being able to completely bypass my own thing
and give the user a direct hook into OpenSSL via _CONF_ is a great
thing to have.  That is what is actual fact in normal user space
applications, if you want to replace that by some
installation-wide policy then this is a nice idea, but it'll take
decades until it reaches the last (maintained) application.

Many programs support multiple TLS/SSL implementations and need to
be able to configure the one which the user actually chooses to
use / is available on the box.  So your proposal needs to be
adhered to by other TLS/SSL providers too in order to release
applications from their compatibility problem.

Of course i need an application internal compatibility layer for
those implementations which don't support a direct _CONF_ hook as
OpenSSL will start to support with v1.0.2 (though reducing my own
thing to only support OpenSSL was one of the first steps i did,
yet support for others will be readded later again).  And for
those i need to know relationships, "what is secure" etc.  But
i also need to know actual protocol names anyway, so whatever
i do, without active maintainership things will rot.  This is why
i would be very happy if there would be "NEWEST", because even
a rotted codebase would be automatically secure -- should the
NEWEST protocol be secure.  And if NEWEST is not supported by some
counterpart server, then the user can still fine-tune and lower as
far as necessary.  I think this is the much better way 'round.

Giving a user an option to actively deselect what is known not to
be secure for a library release that still needs to support old
protocols due to compatibility reasons can't be wrong.
Of course users are capable to understand that a library update is
necessary to overcome a newly detected insecurity.
The maintenance burden of the OpenSSL library seems to be pretty
drastic; regarding these strings those could be placed into ssl.h,
maybe encapsulated in some library-built-time preprocessor toggle.

Surely my own thing can be enhanced a lot, with more configuration
options for users, with adhering to system wide defaults, but i am
only one and that needs more time.
I neither have the time nor the will (i am an elder man in the
end) to spend time on rat racing some stylish internet pages.  If
i want communication i listen to good interprets of classical
music.  Thanks for your consideration.

Ciao,

--steffen