[openssl-users] Disable a cipher suite in openssl.cnf?

[Johann v. Preußen]

Mr. Neugroschl's quest for a simple solution does bring up -- in my 
user-oriented opinion -- a very good follow-on question: "/Why cannot a config 
file be utilized by openssl to simply give access based on an allow/deny 
mechanism that would give users system-wide control in a single place?"./

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 <scott_n at xypro.com 
> <mailto:scott_n at 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.
> ​
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160924/8e36dd41/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3825 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160924/8e36dd41/attachment-0001.bin>