"Salz, Rich via RT" <r...@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 _______________________________________________ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
