Disable a cipher suite in openssl.cnf?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Disable a cipher suite in openssl.cnf?

Scott Neugroschl-2

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?

 

 

---

Scott Neugroschl | XYPRO Technology Corporation

4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 |

 

 

 


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Disable a cipher suite in openssl.cnf?

Richard Moore


On 23 September 2016 at 17:13, Scott Neugroschl <[hidden email]> 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.
 

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 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 <[hidden email]> 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.
 




--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Disable a cipher suite in openssl.cnf?

Salz, Rich

> 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?".

We just haven't gotten around to it yet.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Disable a cipher suite in openssl.cnf?

Viktor Dukhovni

> On Sep 24, 2016, at 7:16 PM, Salz, Rich <[hidden email]> wrote:
>
>>
>> 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?".
>
> We just haven't gotten around to it yet.

The SSL_CONF API (IIRC also in 1.0.2, definitely in 1.1.0) allows
for shared settings in applications that use that API to set the
defaults.  Most applications are not using this yet...

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users