[kea-dev] cryptolink and OpenSSL

[Tomek Mrugalski]

On 17/06/15 21:53, Francis Dupont wrote:
> I worked a lot on the support of RSA (and ECDSA) by the cryptolink library
> which was (and still is) very useful for the secure DHCPv6 experiment.
> I fixed the HMAC code which doesn't implement what the doc describes
> and the corresponding unit tests which don't test correctly the code.
> Note this has no impact in the current use of cryptolink so it can wait
> the next release (aka > 0.9.2).
> The problem is th fix use the last OpenSSL HMAC API which is not supported
> by some old versions of OpenSSL. As IMHO the old HMAC API is broken (some
> critical functions don't return a code one can test even when they can fail)
> I think it is not a problem and OpenSSL without the new API should be
> rejected by configure.
> Today Apple OS X is in this case (but the system OpenSSL is being obsoleted
> so it is not a problem to require the brew (or another package tool) OpenSSL).
> I don't know for RedHat or CentOS, nor if it can be a problem. Note OpenSSL
> is an option, the standard backend is still Botan so it is far to be
> a critical issue...
> Any comment/opinion?
I'm not sure what question are you asking here:
1. Can we make OpenSSL rather than Botan the default crypto lib?
2. Can we require the new OpenSSL version that supports new HMAC API?

For 1, I'm ok with that. It doesn't really matter, as long as the
configure script works similar to what it does today: try to use the
default library and if that fails, tries to use the other one. There's
also a switch to force using one library or the other.

For 2, it's more complicated. We can't require bleeding edge OpenSSL if
it's not available in popular platforms. bind10 did that mistake. They
required very recent versions of python 3 and log4cplus. As a result
people had problems compiling bind10. We won't repeat that mistake in Kea.

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.

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. 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.

Tomek