[erlang-questions] ERL-823: SSL cipher_suites too limited when compiling with OPENSSL_NO_EC=1

[Per Hedeland]

On 2019-01-04 10:38, Andreas Schultz wrote:
> Nicholas Lundgaard <nalundgaard@REDACTED <mailto:nalundgaard@REDACTED>> schrieb am Do., 3. Jan. 2019 um 21:18 Uhr:
> 
>     Hi,
> 
>     I wanted to call ERL-823 (https://bugs.erlang.org/browse/ERL-823) to this list's attention. My company operates Erlang microservices in AWS on a kerl-built OTP installation on Amazon Linux
>     (RedHat/CentOS-based), and we've encountered a serious challenge to upgrading to OTP 21:
> 
> 
> ECC Ciphers are supported since RHEL 7.6 (also newer CentOS versions), Amazon Linux 2018.03 also has support (`openssl ciphers -v` does contain ECDH ciphers).

Actually I think there is some confusion here - also older versions of
RHEL/CentOS(/Fedora?) support ECC cipher suites (I checked CentOS 7.2
just now) - it is only a specific *set of curves* they don't support
(and probably newer versions don't either), due to concerns about
potential patents.

And there was actually a time when you *had* to use the brutal
OPENSSL_NO_EC=1 workaround/hack to get OTP crypto to work on these
systems, since crypto.c couldn't handle this "partial" exclusion of
curves - depending on how you built it (excluding static linking* of
libcrypto), you would get a failure either at build or run time.

But that was long ago, crypto.c was fixed in this respect already for
OTP 17, in https://github.com/erlang/otp/commit/8837c1be2ba, by -
Andreas Schultz! Thanks for that!:-)

So, if you use OTP 17 or newer:

- If you build with the libcrypto shipped with RHEL/CentOS, it will
   "just work", without the OPENSSL_NO_EC hack.

- If you for some reason build with a libcrypto that *includes* the
   curves that are excluded on those systems, you can still do a build
   that works there, *and* makes ECC suites in general available, by
   using OPENSSL_NO_EC2M=1 *instead* of OPENSSL_NO_EC=1.

I guess the moral is that if you are given a recipe for some problem,
make sure that you understand why it is needed, so you can stop using
it when the actual problem is fixed...:-)

*) I Am Not A Lawyer, but I will still advise at least those shipping
commercial products based on Erlang/OTP to look carefully into the
general legal issues with statically linking libcrypto into those
products. And after having done that, to think again about the wisdom
of doing the static linking specifically to be able to include
algorithms that may be patented.

--Per Hedeland