Pull Request submitted yesterday via GitHub, currently testing and refining port of this port on pfSense 2.3.2: https://github.com/freebsd/freebsd-ports/pull/52 BIND-9.10+ provides a native PKCS#11 client [1] as a simpler and more recent alternative to interface with PKCS#11 providers, such as SoftHSMv2, compared to using High Security Modules (HSM) via OpenSSL. The blog [2] illustrates how to use BIND's pkcs11-* and dnssec-* tools in native PKCS11 mode to generate DNSSEC Key and Zone Signing Keys in a SoftHSMv2, and to sign zones' resource records. This PR includes patches which I have hand-picked from Fedora 23 port's bind-9.10.4-1.P2.fc23.src.rpm patch file .../rpmbuild/SOURCES/bind-9.10-dist-native-pkcs11.patch. Note that I removed DLZ while closely following the "native PKCS11" patch of the Fedora port, although presently unsure if this necessary. Maybe it is cleaner, or even necessary, to have separate port like "bind910-pkcs11..." in Linux, or a "flavour" thereof like OpenBSD ports system provides? This is my first PR for FreeBSD, please be kind :-) Thanks. [1] Native PKCS#11 mode https://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/Bv9ARM.ch04.html#id-1.5.12.7 [2] DNSSEC with BIND 9.10 and native PKCS#11 support (BIND and SoftHSM) http://arunnsblog.com/2016/01/18/dnssec-with-bind-9-10-and-native-pkcs11/
I tried the native PKCS#11 thingie when it came around to make sure the port option option worked, and, well, it worked, what does this adds ? Also, has this been submitted upstream ?
(In reply to Mathieu Arnold from comment #1) > what does this adds ? Well, as I tried to summarize in my description, it adds necessary build options so that native PKCS11 mode is built, so that BIND's DNSSEC tools and in-line signing can use HSMs that make a PCKS11 provider available. Please see references [1] and [2] for additional details and example of use. > Also, has this been submitted upstream ? According to my current understanding, there is nothing to "upstream" to ISC/BIND, or elsewhere. My changes are only using configuration options that BIND had available since 9.10. These changes are local to the FreeBSD port of BIND only, similar to the ports in Fedora "bind-pkcs11", "bind-pkcs11-utils", "bind-pkcs11-libs". This port is the basis for another port/package in pfSense 2.3.2, which is however "downstream" of FreeBSD 10.3, e.g. pfSense uses ports from FreeBSD.
(In reply to Mathieu Arnold from comment #1) > I tried the native PKCS#11 thingie when it came around to make sure the port option option worked, and, well, it worked, what does this adds ? Or, in other words, if you try to go through the example use of blog post [2] without my patches, at latest the following command will fail with a fatal error: dnssec-keyfromlabel-pkcs11 -v 9 -E /usr/lib64/pkcs11/libsofthsm2.so -a RSASHA256 -l pkcs11:label=sample_ksk?pin-source=file:/etc/token_pin -f KSK example.com dnssec-keyfromlabel: fatal: failed to get key example/RSASHA256: no PKCS#11 provider
(In reply to Rolf Sommerhalder from comment #2) > (In reply to Mathieu Arnold from comment #1) > > > what does this adds ? > > Well, as I tried to summarize in my description, it adds necessary build > options so that native PKCS11 mode is built, so that BIND's DNSSEC tools and > in-line signing can use HSMs that make a PCKS11 provider available. > Please see references [1] and [2] for additional details and example of use. > > > Also, has this been submitted upstream ? > > According to my current understanding, there is nothing to "upstream" to > ISC/BIND, or elsewhere. My changes are only using configuration options that > BIND had available since 9.10. These changes are local to the FreeBSD port > of BIND only, similar to the ports in Fedora "bind-pkcs11", > "bind-pkcs11-utils", "bind-pkcs11-libs". > > This port is the basis for another port/package in pfSense 2.3.2, which is > however "downstream" of FreeBSD 10.3, e.g. pfSense uses ports from FreeBSD. It may be that I don't understand anything of what you are saying, but to sum up: The default PKCS#11 interface is not complete and needs a patch to work correctly. As it also happens on Fedora, it is not FreeBSD specific, but a bug in BIND9. As it is a bug, and unless the ISC is being difficult and says it is not, it should be sent upstream so that it is included in futures releases so that it works for everybody.
(In reply to Mathieu Arnold from comment #4) BIND's autoconf option switches offer two ways to interface with HSMs that make PKCS#11 providers available, such as SoftHSM v2 does (see Reference [1] for a in-depth description): a) The "old way" where named and its pkcs11-* and dnssec-* tools) talk to OpenSSL (library). Only OpenSSL then talks to HSMs via the PKCS11 provider (library). That's how FreeBSD's port of BIND910 is currently configured per default, as well as other *BSDs and various Linux distributions. Probably, because the "OpenSSL way" was the first and only option available before BIND-9.10. b) BIND-9.10 added an alternate "new way" with the "native PKCS11 mode" which enables named (and its pkcs11-* and dnssec-* tools) to talk directly to the PKCS11 providers of HSMs, without intermediary of OpenSSL. My PR switches from the in-direct "old way" a) to the direct "new way" b) to talk to HSMs. BIND still supports both configurations, and the porter has to chose one. Unfortunately, setting the radio button in 'make config" that just activates '--enable-native-pkcs11' alone, as the FreeBSD port currently does, is not sufficient to get a BIND package with named, pkcs11-* and dnssec-* tools with working DNSSEC support. At first sight, it might actually be tempting to provide a new, second port under a different name such as "bind-pkcs11" (like at least Fedora did). Unless FreeBSD ports has a mechanism similar to "flavours" in OpenBSD which allows building binary packages with flavours a) or b) from the same source port "bind910"? But while writing the previous paragraph, I just noticed that the radio buttons "SSL" xor "NATIVE_PCS11" under "Choose which crypto engine to use" actually allow the user to chose among "flavours" a) or b) while doing 'make config'. The problem is that the current port is incomplete for "NATIVE_PKCS11" way, e.g. the resulting binary package does not allow in-line DNSSEC signing in HSMs using the native PKCS11 mode. My Pull Request is an attempt to fix that "flavour" of the port. Does that make any sense, or is my current perception completely and utterly wrong?
(In reply to Rolf Sommerhalder from comment #5) > Does that make any sense, or is my current perception completely and utterly > wrong? I've exchanged a few emails with the ISC since my last comment here, and, so, it mostly is wrong. BIND9 can only have *one* crypto library, so it either uses OpenSSL for all its crypto, or it uses a PKCS#11 provider directly, for all of it, you can choose that with the config option when building the port. What the Fedora patch, in fedora, does, is build two BIND9, one with OpenSSL and one with PKCS#11, so that you can have both installed at the same time. But I don't understand what having two incompatible BIND9 installations achieve. If you build the port with NATIVE_PKCS11, is there something that does not work when running the dnssec-* commands with the correct PKCS#11 engine library ?
(In reply to Mathieu Arnold from comment #6) > I've exchanged a few emails with the ISC since my last comment here, and, so, it mostly is wrong. OK, great that you have access to ISC! > If you build the port with NATIVE_PKCS11, is there something that does not work when running the dnssec-* commands with the correct PKCS#11 engine library ? So I went back and built the bind910 port again without my changes on FreeBSD 10.3, just with the NATIVE_PKCS11 radio button. Following the blog post [2], dnssec-* commands fail as follows (this time I show the FreeBSD case, not like Comment 3 where I had mistakenly quoted another error from the Fedora case): root@freebsd:~ # dnssec-keyfromlabel -l 'pkcs11:object=sample_ksk;pin-source=/etc/token_pin' -a RSASHA256 -f KSK -v3 -E /usr/local/lib/softhsm/libsofthsm2.so example.com dnssec-keyfromlabel: fatal: failed to get key example.com/RSASHA256: built with no crypto support So, is it time to open a case upstream with ISC then? Thanks!
(In reply to Rolf Sommerhalder from comment #7) > (In reply to Mathieu Arnold from comment #6) > > > I've exchanged a few emails with the ISC since my last comment here, and, so, it mostly is wrong. > > OK, great that you have access to ISC! Well, I sent an email to the email they have for bind9 bugs, it is in most of their announcements, anyone can do that :-p > > If you build the port with NATIVE_PKCS11, is there something that does not work when running the dnssec-* commands with the correct PKCS#11 engine library ? > > So I went back and built the bind910 port again without my changes on > FreeBSD 10.3, just with the NATIVE_PKCS11 radio button. > > Following the blog post [2], dnssec-* commands fail as follows (this time I > show the FreeBSD case, not like Comment 3 where I had mistakenly quoted > another error from the Fedora case): > root@freebsd:~ # dnssec-keyfromlabel -l > 'pkcs11:object=sample_ksk;pin-source=/etc/token_pin' -a RSASHA256 -f KSK -v3 > -E /usr/local/lib/softhsm/libsofthsm2.so example.com > dnssec-keyfromlabel: fatal: failed to get key example.com/RSASHA256: built > with no crypto support > > So, is it time to open a case upstream with ISC then? Thanks! I'll forward them that, see what they say.
(In reply to Rolf Sommerhalder from comment #7) > Following the blog post [2], dnssec-* commands fail as follows (this time I > show the FreeBSD case, not like Comment 3 where I had mistakenly quoted > another error from the Fedora case): > root@freebsd:~ # dnssec-keyfromlabel -l > 'pkcs11:object=sample_ksk;pin-source=/etc/token_pin' -a RSASHA256 -f KSK -v3 > -E /usr/local/lib/softhsm/libsofthsm2.so example.com > dnssec-keyfromlabel: fatal: failed to get key example.com/RSASHA256: built > with no crypto support About that: > => can you check the configure log? There was a bug (was = fixed now) > in configure which can mess the crypto selection and > can give no crypto at all (i.e., not OpenSSL nor PKCS#11).
(In reply to Mathieu Arnold from comment #9) >About that: > >> => can you check the configure log? There was a bug (was = fixed now) >> in configure which can mess the crypto selection and >> can give no crypto at all (i.e., not OpenSSL nor PKCS#11). OK, in config.log of the unmodified port I see a bunch of "error" messages, although the build of the package completes, such as the examples below. But nothing complains about the keyword "crypto" or so. What to search for? Can you eventually provide any bug, patch, or revision IDs that I shall try to build and test with instead? Thanks! ... configure:3356: checking for C compiler version configure:3365: cc --version >&5 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: x86_64-unknown-freebsd10.3 Thread model: posix configure:3376: $? = 0 configure:3365: cc -v >&5 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: x86_64-unknown-freebsd10.3 Thread model: posix Selected GCC installation: configure:3376: $? = 0 configure:3365: cc -V >&5 cc: error: argument to '-V' is missing (expected 1 value) cc: error: no input files configure:3376: $? = 1 configure:3365: cc -qversion >&5 cc: error: unknown argument: '-qversion' cc: error: no input files configure:3376: $? = 1 configure:3396: checking whether the C compiler works configure:3418: cc -O2 -pipe -isystem /usr/local/include -DLIBICONV_PLUG -fstack-protector -fno-strict-aliasing -isystem ... configure:7017: checking how to run the C preprocessor configure:7087: result: cpp configure:7107: cpp -isystem /usr/local/include -DLIBICONV_PLUG conftest.c configure:7107: $? = 0 configure:7121: cpp -isystem /usr/local/include -DLIBICONV_PLUG conftest.c conftest.c:9:10: fatal error: 'ac_nonexistent.h' file not found #include <ac_nonexistent.h> ^ 1 error generated. configure:7121: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "BIND" | #define PACKAGE_TARNAME "bind" | #define PACKAGE_VERSION "9.10" | #define PACKAGE_STRING "BIND 9.10" | #define PACKAGE_BUGREPORT "bind9-bugs@isc.org" | #define PACKAGE_URL "https://www.isc.org/downloads/BIND/" | /* end confdefs.h. */ | #include <ac_nonexistent.h> configure:7150: checking for ANSI C header files configure:7254: result: yes configure:7267: checking for sys/types.h configure:7267: result: yes configure:7267: checking for sys/stat.h configure:7267: result: yes configure:7267: checking for stdlib.h configure:7267: result: yes ...
Just noticed that ISC now provides read-only Guest access to their ticket system: https://bugs.isc.org/Public/ This allows me to catch up and understand the other side of the conversation with with the experts at ISC regarding this thread :-) https://bugs.isc.org/Public/Bug/Display.html?id=43093 Eventually, I make another attempt to build BIND 9.10 or 9.11 such that it uses its "new" native PKCS11 interface to "PCKS11 providers" of some Hardware Security Modules (HSM), that expose APIs like SoftHSM does, without involving OpenSSL as an intermediary...
Expired port removed.