2

(This is hypothetical, but based on a real-life problem I've had)

Context:

I am developing an (embedded) device which includes a few exposed network services. I'm responsible for security, not developing these services, so I don't know how they're built.

I do some testing (send targeted Client Hello messages to the device services with specific cipher suites) and find that some of these services accept weak TLS cipher suites.

Problem:

I am now tasked with addressing this problem, preferably by fixing the problem as far back in the stack as possible (e.g. I would prefer to avoid having to look at the code/configuration of each individual application and would instead like to fix it at the system level).

Assumptions:

  1. I know that OpenSSL is the only crypto library/program in use on the system.

Now some questions:

  1. What options do I have for preventing network services from allowing weak TLS ciphers? (e.g. change OpenSSL itself, change OpenSSL configuration files, change OS configuration, etc.)

  2. Which options are reasonably "safe"? e.g. I suppose I could modify the OpenSSL code and remove every mention of these cipher suites, recompile, and integrate. This would prevent applications from sending the suites (even if they ask for them). However, this seems like a dangerous solution and difficult to maintain long term.

  3. Is this even possible, or do I necessarily need to look at each service?

4

What options do I have for preventing network services from allowing weak TLS ciphers?

Changing the application or the applications configuration is one option, provided that the version of OpenSSL on the device actually supports the stronger ciphers you want.

Changing OpenSSL and restricting the available ciphers is another one, but make sure that all applications on the device actually link against this modified OpenSSL. And it is not trivial: you cannot simply forbid for example MD5 as long as you want to allow TLS 1.0 or TLS 1.1 since it is actually used there even if not needed for ciphers. So you might try to remove support for specific ciphers, but this might actually break unmodified applications on your device.

You might also need to use a newer version of OpenSSL to support the configuration you want, in which case you not only need to make sure that the applications are linked against the new version but you should also recompile the applications since the API might have changed. And, some API changes have actually introduced behavior changes, which means that you should properly test if the applications still work as expected, even in edge cases.

Changing some global OpenSSL config will not help since this does not specify which ciphers are supported by the application.

Another option in some cases is to have some secure reverse proxy on the device which only allows safe configuration and which "shadows" the weak configuration from the older application. But if this works depends on the specific use case.

  • Thanks, this is really good info. Regarding the dangers of breaking applications... Does that apply only if I am manually changing the OpenSSL configuration, or does it include standard OpenSSL build configuration (like what Jenessa mentioned below)? In other words, if I disable cipher suites when configuring OpenSSL, will applications likely keep working? – Josiah Aug 23 '19 at 15:44
  • 1
    @Josiah: Application which rely on a specific cipher or algorithm will stop working if you disable it. Applications which relay on a specific behavior of OpenSSL might fail if newer versions changed this behavior. This is for example true with the behavior of SSL_read and SSL_write in some edge cases around non-blocking sockets. It is also true with TLS 1.3, again specifically with non-blocking sockets. – Steffen Ullrich Aug 23 '19 at 15:53
2

It can't be changed globally in OpenSSL's configuration, but recompiling without certain ciphers is easy. Just give the no-[cipher-to-disable] parameter to ./configure.

For example

./config no-ssl2 no-ssl3 no-tls1 no-tls1_1 no-dtls no-dtls1_1 no-ssl2-method no-ssl3-method no-tls1-method no-tls1_1-method no-dtls-method no-dtls1_1-method no-weak-ssl-ciphers
make

will build OpenSSL without weak protocols

  • 'weak-ciphers' is a config/Configure option only in 1.1.0 up, where the default is already 'no'; in 1.0.x you can disable rc4 and des individually, but des algorithm includes 3des ciphersuites which you may or may not want to disable (cf sweet32). Also in 1.1.0 up ssl3 and ssl3-method are default no, and ssl2 and ssl2-method don't exist at all. – dave_thompson_085 Aug 24 '19 at 6:27
0

Tunneling/proxying

One approach that's has a bunch of disadvantages, but is always usable without changing the services (it may be that the service not only accepts weak TLS cipher suites, but requires weak TLS suites, perhaps it's configured to not support anything newer than SSLv3) is SSL tunneling/proxying.

I.e. you configure the services (and the host and the firewall) so that they are not accessible directly from outside. Then you use some "known good" software to accept only "proper" TLS connections with all the appropriate settings, and forward them (locally) to the appropriate services. Stunnel is one option to do that; and as far as I understand, nginx can also be used as a tls reverse proxy.

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.