1

When faced with an application that does not allow for configuring cipher suites to use, is there another way to blacklist cipher suites at the openssl shared library level without rebuilding from source?

Added detail:

The server application in this specific case is pgpool2. As far as I can tell, it allows the openssl library to offer any protocol or cipher suite it has to offer by not setting any restrictions in the context, here. I have gotten confirmation from the pgpool-general mailing list that cipher suites are not configurable. However, I doubt pgpool2 is the only application to use openssl library in this way and so am looking for a solution outside of the application.

Improve this question
6
  • II don't know off-hand, but generally in client server communication the cipher suite used is negotiated, if you can't configure that in your application, maybe can you control the security level from the other end-point?
    – HBruijn
    Aug 22, 2018 at 12:52
  • Very true, however, I want to cover cases where I might not 100% control or trust the client.
    – virullius
    Aug 22, 2018 at 13:14
  • 1
    Are you saying that the application has a hard-coded list of cipher suites and it doesn't expose this as a configuration option? The first step is to yell very loudly at the developer.
    – Michael Hampton
    Aug 22, 2018 at 13:24
  • Not quite that bad. As far as I can tell, it initializes OpenSSL without limiting the cipher suites or protocol versions in any way; allowing any the shared library has to be offered.
    – virullius
    Aug 22, 2018 at 13:36
  • This may be overkill but if you're running a Red Hat variant you could enable FIPS mode. Turns off a lot of ciphers but if actually works reasonable well.
    – doneal24
    Aug 22, 2018 at 13:59

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .