Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. cryptolink and OpenSSL (Francis Dupont)
2. Re: cryptolink and OpenSSL (Tomek Mrugalski)
3. Re: cryptolink and OpenSSL (Francis Dupont)
----------------------------------------------------------------------
Message: 1
Date: Wed, 17 Jun 2015 19:53:34 +0000
From: Francis Dupont <[email protected]>
To: Kea Dev List <[email protected]>
Subject: [kea-dev] cryptolink and OpenSSL
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
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?
Regards
Francis Dupont <[email protected]>
------------------------------
Message: 2
Date: Thu, 18 Jun 2015 10:31:30 +0200
From: Tomek Mrugalski <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] cryptolink and OpenSSL
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
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
------------------------------
Message: 3
Date: Thu, 18 Jun 2015 11:46:13 +0000
From: Francis Dupont <[email protected]>
To: Tomek Mrugalski <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] cryptolink and OpenSSL
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
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 <[email protected]>
PS: the OpenSSL log says:
commit 87d52468aa600e02326e13f01331e1f3b8602ed0
Author: Dr. Stephen Henson <[email protected]>
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).
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 15, Issue 8
**************************************
