[kea-dev] cryptolink and OpenSSL

[Francis Dupont]

Tomek Mrugalski writes:
> I'm not sure what question are you asking here:
> 1. Can we make OpenSSL rather than Botan the default crypto lib?

=> no, I am fine with Botan as the default backend even this point
is arguable.

> 2. Can we require the new OpenSSL version that supports new HMAC API?

=> this is the question (new APIs were introduced for 1.0.0 versions
so 0.9.7 (sic) or 0.9.8 (old but still in use) won't work).

> For 2, it's more complicated. We can't require bleeding edge OpenSSL if
> it's not available in popular platforms.

=> it is not bound to OpenSSL versions but what is really provided.
So configure has to check. Now OpenSSL is an option so IMHO it is not
a real problem to enforce the use of new/fixed APIs.

> In my opinion, we should be able to use whatever is installed by default
> in more popular OSes. We may tweak the list a bit, but it seems that
> Ubuntu, RHEL, FreeBSD and Mac OS look like the minimal subset of systems
> we should check OpenSSL compatibility on.

=> Ubuntu, Fedora, etc should not be a problem, BSDs too. I don't know
for RHEL and CentOS, this is why we have this discussion. OS X i
different because the official position of Apple is to fully drop the
support of OpenSSL so I am fine to require the brew OpenSSL for instance
for people who prefer OpenSSL over the (brew) Botan.

> Now, I understand that working with old and new API is a pain. So what
> you can consider is to have the whole secure DHCP stuff depend on
> necessary OpenSSL.

=> in fact HMAC is used for TSIG, secure DHCPv6 uses RSA which is
implemented by Botan too (i.e., secure DHCPv6 is in the context because
it triggers the discovery of the problem, it is not impacted itself).

> If too old version is detected, Kea would compile,
> but with secure dhcp disabled. That seems like a reasonable compormise -
> no spaghetti code, no old & new API support etc.

=> I agree about the "no spaghetti code" in particular to support something
which is known to be wrong. My proposal is to add when the cryptolink
update will be ready a check for the HMAC API in configure.ac so
a --with-openssl pointing to a too old and buggy OpenSSL will raise an
error.
To summary is this proposal acceptable for RHEL & clone users?

Regards

Francis Dupont <fdupont at isc.org>

PS: the OpenSSL log says:

commit 87d52468aa600e02326e13f01331e1f3b8602ed0
Author: Dr. Stephen Henson <steve at openssl.org>
Date:   Sun Nov 2 16:00:39 2008 +0000

    Update HMAC functions to return an error where relevant.

The cryptolink fixed code will use HMAC_CTX_copy (easier to check with
a grep in <openssl...>/crypto/hmac/* or for the include openssl/hmac.h).

Note that according to packages repo RHEL and CentOS 6 and 7 are fine
(they use OpenSSL 1.0.1 by default).