0

I would like to compile OpenSSL from source. There are a number of configuration options I can use when compiling it. I prefer it to be as secure and hardened as possible, and it will eventually be used when compiling Apache HTTPD. There are some configuration options that seem obvious for this goal, such as no-ssl2 and no-ssl3. What other options should I use and why? The options are all documented on the OpenSSL website, but for some of them it difficult for me to discern the effects, or pros and cons, of using each one.

What are the pragmatic options to choose that will make OpenSSL hardened?

Dylan Klomparens
  • 634
  • 2
  • 9
  • 22
  • If it's you that control the certificate on the server, why the use to remove un-used protocol ? as anyway you control the remote end. – yagmoth555 Jan 27 '17 at 16:36
  • @yagmoth555 doing so mitigates things like downgrade attacks. – Jason Martin Jan 27 '17 at 17:49
  • Doesn't seem like adding anything to security, but if you insist: ./Configure linux-x86_64 enable-camellia enable-ec enable-idea enable-mdc2 enable-rc5 enable-tlsext enable-asm enable-gmp -lgmp no-krb5 enable-rfc3779 no-sctp no-ssl2 no-ssl3 enable-heartbeats enable-zlib --prefix=/usr --openssldir=/etc/ssl --libdir=lib64 threads no-weak-ssl-ciphers no-ssl-trace no-ssl3-method no-ssl3 no-rmd160 no-rc5 no-rc4 no-rc2 no-md4 no-md2 no-heartbeats no-gost no-ec-nistp-64-gcc-128 no-ec2m no-dsa no-deprecated no-camellia no-blake2 no-bf no-afalgeng no-srp no-idea – Anubioz Jan 27 '17 at 18:40
  • @Anubioz: doesn't look like a sane list to add both 'no-camellia' and 'enable-camellia' in the same list, and some other stuff is also weird. – schlenk Jan 27 '17 at 22:32
  • 2
    @schlenk the question itself is wrong, so my comment was kind of a joke. You don't actually getting secure by using self-compiled packages, since they are *guaranteed* to be updated much less frequently (you can't have that much free time, to recompile everything with each new version, lol). So instead of asking for openssl compilation options, which are clearly offtopic here (not enthusiast, but business environments), he should have asked how can he achieve A+ sslabs rating with whatever version of OpenSSL his environment has provided.. – Anubioz Jan 27 '17 at 22:43
  • @Anubioz: Kind of depends on what your job is. If the job descriptions says 'we want a statically linked apache httpd' you might have to bite the bullet and setup your tool chain to build it from scratch (especially on windows, where the quality of prebuild openssl libs is pretty bad). – schlenk Jan 27 '17 at 22:58
  • @schlenk Sure, windows OpenSSL is a mess (BTW, I've got a great guide on compiling it [here](http://stackoverflow.com/questions/18486243/how-do-i-build-openssl-statically-linked-against-windows-runtime/41815728#41815728) :)). That's why running Apache under windows is also offtopic on serverfault :))) – Anubioz Jan 27 '17 at 23:18
  • @Anubioz: nice guide, but adding zlib / compression to openssl is a bad idea actually (CRIME related). – schlenk Jan 27 '17 at 23:22
  • Well, if you're using git versions of everything, you are safe, since compression is disabled (i haven't found any ways to enable it neither server-side, nor client-side, despite everything is compiled with zlib). I guess it is obsolete indeed. Thanks for the info! – Anubioz Jan 27 '17 at 23:42
  • 1
    I think you could call "BoringSSL" the hardened version of OpenSSL. You could give that one a try. – StackzOfZtuff Jan 28 '17 at 07:24

1 Answers1

0

It really all depends on your expected clients and the certificates you use. If you control both clients and servers, pick only TLS 1.2 (or maybe TLS 1.3 once it is final), take some ECDHE stuff for perfect forward secrecy, use the assembly version (it can use Intel's AESNI instructions, without it gets a lot slower) and throw out everything you do not need. As small as possible.

If you do not control the clients, use what your clients need, but use common sense (e.g. if your clients are IE on Windows XP, you have not a single secure cipher left, so it is a lost cause).

The exact list of flags depends on many factors: e.g. openssl version, your OS, compiler/CPU, etc.

Typically linux distros do a fairly good job at picking not too bad compile flags, the enterprise style ones (RHEL, SLES etc.) usually use the FIPS mode of openssl which is meant to be somewhat hardened (see https://www.openssl.org/docs/fips.html ).

schlenk
  • 183
  • 5