2

I'm new to OpenSSL configuration and am trying to determine if OpenSSL can have TLSv1 and certain insecure ciphers disabled system-wide in any way on Linux, using system-wide configuration or custom build(s) of OpenSSL?

From what I've read on the web, it sounds like this can't be done at the system level but only at the application level, as applications like Apache and Nginx are linked against a particular version of OpenSSL, which is then configured through the application's configuration itself.

So to disable TLSv1 in Apache it would be an Apache configuration change, and to disable TLSv1 in Nginx it would be an Nginx configuration change.

My question is: Can a custom version of OpenSSL be built which disables TLSv1 and particular ciphers, which is then installed system-wide and used by Apache and Nginx, as well as any applications that need OpenSSL on the system?

Even if Apache and Nginx used different versions of OpenSSL, could 2 separate, custom versions of OpenSSL be built and deployed on the system that would then be used by these applications?

I've been reviewing the OpenSSL Cookbook and OpenSSL wiki, but feel I'd like to get some advice on how to proceed.

  • 1
    You could compile OpenSSL yourself and exclude everything you need to exclude at compile time. This is even stronger than configuration changes as not compiling at all some ciphers make you sure never to be able to use them even if you failed at your configuration. But having multiple installations of OpenSSL on the same server will be complicated to manage. – Patrick Mevzek Jun 26 '18 at 13:24
3
+25

My question is: Can a custom version of OpenSSL be built which disables TLSv1 and particular ciphers, which is then installed system wide and used by Apache and Ngnix, and any applications that need OpenSSL on the system?

If I'm understanding your question correctly, you wish to disable TLSv1 at compile time, so openssl won't support the protocol. If that's what you are after, there are two flags that apply, and this is the official description:

no-<prot>

Don't build support for negotiating the specified SSL/TLS
protocol (one of ssl, ssl3, tls, tls1, tls1_1, tls1_2,
tls1_3, dtls, dtls1 or dtls1_2). If "no-tls" is selected then
all of tls1, tls1_1, tls1_2 and tls1_3 are disabled.
Similarly "no-dtls" will disable dtls1 and dtls1_2. The
"no-ssl" option is synonymous with "no-ssl3". Note this only
affects version negotiation. OpenSSL will still provide the
methods for applications to explicitly select the individual
protocol versions.


no-<prot>-method

As for no-<prot> but in addition do not build the methods for
applications to explicitly select individual protocol
versions. Note that there is no "no-tls1_3-method" option
because there is no application method for TLSv1.3. Using
individual protocol methods directly is deprecated.
Applications should use TLS_method() instead.

You should pay attention to the final note on the no-tls flag, which states that it only affects the negotiation.

2

Sadly, you can't guarantee that applications stop using unsafe configurations with a system wide config file. OpenSSL (and potentially all apps that link against it) need to be recompiled with the unsafe protocol and cipher options disabled.

And if you got OpenSSL locked down, some app uses GnuTLS, NSS, or another implementation.

So if you want to ensure that your applications use a sane TLS configuration, you have to use application-specific configuration files.

That being said, Redhat seems to support system-wide crypto config files in Fedora, which someday might end up in RHEL.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.