Ensuring all network services on a device use strong TLS cipher suites

Question

(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?

Answer 1

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.

Answer 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

Answer 3

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.