the benefits of such an implementation are clearly manifold from the admin side. as a vulnerability arises, a weakness is revealed, a specific requirement is desired; a user can close out or enable any use of that avenue in a heartbeat ... permanently (/i.e./, persisting through updates), temporarily until a patch can be applied or a new release installed, or when requirements change. this would also greatly ease using openssl (think "views" in bind: although openssl's approach does not have to be as "unified" as bind's single config file) so that openssl could be tailored to different access methods such as intranet, tunnels, VPN's, et cetera.
from the dev side i would think this approach would also have benefits worth exploring. FIPS immediately comes to mind. its hard-coded approach and protracted separate compliance certification could be distilled down to checking a hash (or some such security check) on a special over-riding config file when FIPS-enabled is encountered. this would also speed access to standards creators to modify the config file on the fly instead of interludes that can consume years despite industry-wide documentation/recognition that something must be done. then, openssl merely needs to be updated with the new hash or whatever.
in fact, openssl could really foster transparency within the whole auth/encrypt process by creating its own allow/deny master listing that a user could modify at will without the need to be conversant at any type of coding. providing a more inclusive and user-friendly process also could, perhaps, forestall app's from "going-it-alone" or using other vendors such as experienced with openssh and lua.
i DO realize that such a "modular" approach instead of "all-or-nothing" is not a simple matter from the dev side, but permitting the user an ability to go /a la carte/ according to specific needs seems highly attractive. it could also enable user migration scheduling (think sha1 to sha2, for instance) to keep pace with internal systems integration, configuration, and updating.
there are also matters like the 25519 family which "enjoyed" a decade in virtual limbo until recently emerging as the "cats-meow" of speed and security (1. non-NSA/-NIST; 2. https://tools.ietf.org/html/draft-ietf-ipsecme-safecurves-03; and 3. https://ed25519.cr.yp.to). perhaps if more people saw that it was available via openssl (assuming openssl made it so) and did earlier experimenting with it the hiatus could have been foreshortened and everyone would have benefited. i know openssl cannot include /everything/, but this particular process is Daniel J. Bernstein <https://en.wikipedia.org/wiki/Daniel_J._Bernstein> after all and its "pluses" well-documented and long-known.
BUDGETING: i cannot image the large-donor base NOT being enthusiastic re this approach. i also certainly see where openssl could attract new and more one-time/smaller donors to such a "crowd funding" project that exhibits a very real and visible translation of time to money.
Thank you, Johann v. Preußen On 2016.Sep.24 08:04, Richard Moore wrote:
On 23 September 2016 at 17:13, Scott Neugroschl <scot...@xypro.com <mailto:scot...@xypro.com>> wrote:Hi, I’m afraid the man page on the conf file is not particularly clear. I’m looking at mitigating CVE-2016-2183 (SWEET32), and am not sure how to disable the DES and 3DES suites in the conf file. Can someone give me a hand? You can't disable them in the openssl config file, you should do it in the cipher suite configuration of the affected application.Cheers Rich.
smime.p7s
Description: S/MIME Cryptographic Signature
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
