Bug 594 - Support nettle for libunbound as an alternative to OpenSSL
Support nettle for libunbound as an alternative to OpenSSL
Status: RESOLVED FIXED
Product: unbound
Classification: Unclassified
Component: server
unspecified
All Linux
: P5 enhancement
Assigned To: unbound team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-07-06 01:10 CEST by Simon Arlott
Modified: 2015-11-17 14:22 CET (History)
2 users (show)

See Also:


Attachments
libunbound: optionally use libnettle for crypto (28.75 KB, patch)
2015-11-07 12:41 CET, Luca Bruno
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Arlott 2014-07-06 01:10:02 CEST
This is blocking the inclusion of gnutls-dane on Debian/Ubuntu as gnutls-dane depends on libunbound which then depends on NSS/OpenSSL:
http://lists.alioth.debian.org/pipermail/pkg-gnutls-maint/2013-October/005243.html
http://lists.alioth.debian.org/pipermail/pkg-gnutls-maint/2013-October/005244.html
Comment 1 Wouter Wijngaards 2014-07-07 09:16:51 CEST
Hi Simon,

That would be a big change.  The nettle library is GPL licensed.

Also, like the libNSS option now, it may only create a subset of unbound, as the SSL support is missing (or even harder to port).

I would very much like gnutls-dane to work.  And it is unfortunate that this creates a package-license-SSL library 'knot'.

Best regards, Wouter
Comment 2 Simon Arlott 2014-07-07 13:37:30 CEST
Nettle is available under both GPLv2 and LGPLv3, so it should be practical to link libnettle with libunbound and use it in a GPLv2 or GPLv3 application. (Other applications with less restrictive licences can use it as LGPLv3).

Is the SSL support required for most users of libunbound? It would only need to support plaintext DNS to a local resolver.

The other option would be to add support GnuTLS but then you have a circular dependency preventing libgnutls-dane from ever being merged into libgnutls.
Comment 3 Luca Bruno 2015-11-07 12:41:42 CET
Created attachment 300 [details]
libunbound: optionally use libnettle for crypto
Comment 4 Luca Bruno 2015-11-07 12:49:58 CET
libnettle is dual-licensed under GPL2+ and LGPL3+, so I think it should be fine for the unbound project.

The patch attached above allows for building libunbound and its testsuite (not the whole project!) against libnettle, removing the need for openssl/nss without introducing dependency loops on gnutls.

Testsuite passes here, except for custom DSA signatures (not specified anywhere in RFC?) which I'm ignoring in tests.

I'm keeping this patchset updated on a feature-branch on github:
https://github.com/lucab/unbound/commits/lucab/libunbound-nettle
Comment 5 Wouter Wijngaards 2015-11-17 10:47:06 CET
Hi Luca, Simon,

Applied the patch!

I have made a number of edits, to improve it.  Some warnings about signedness and variable declaration after statement removed.  The nsec3-hashing code needs a sha1_ctx_init before the ctx_update calls in the loop (but it worked before and after that fix in the unittest).  The Makefile has -lssl not removed but using substitution for that so openssl can link with -lssl, but nettle won't.  The random generator does not seed with a uint32 but tries to use getentropy (which tries to use /dev/random) for entropy.

Thank you for the patch.  I like how the validator/val_secalgo.c setup is working to accommodate additional crypto libraries.  I fear it will not be that easy for TLS support.

Best regards, Wouter
Comment 6 Luca Bruno 2015-11-17 11:21:14 CET
> Some warnings about signedness and variable declaration after statement removed.

My compiler didn't warn me, my bad.

> The nsec3-hashing code needs a sha1_ctx_init before the ctx_update calls in the loop (but it worked before and after that fix in the unittest).

It worked because according to nettle documentation "sha1_digest also resets the context in the same way as sha1_init". But an explicit call is clearer, agreed.

> The Makefile has -lssl not removed but using substitution for that so openssl can link with -lssl, but nettle won't.

Definitely better.

> The random generator does not seed with a uint32 but tries to use getentropy (which tries to use /dev/random) for entropy.

I coded this mistakenly starting from an older checkout, without getentropy. Thus the yarrow part kept doing as the openssl counterpart was doing before getentropy.

What about custom DSA signature, instead? Any plan to get them standardized or at least documented anywhere? Or is it ok to just not validate them?
Comment 7 Wouter Wijngaards 2015-11-17 11:25:50 CET
Hi Luca,

I think the patch was well-coded :-)

The 'custom' DSA signatures, are mistaken signatures generated by (an old version I hope?) of ldns.  LDNS was used to construct a lot of unbound's tests.  Since there is no DSA dnssec deployment except test setups, I believe, this is likely not a problem.  The signature bytes are encoded weirdly, I think is the only issue.

Best regards, Wouter
Comment 8 Luca Bruno 2015-11-17 11:43:06 CET
I understand. I have however some bad feelings on having different behaviors between NSS/OpenSSL and Nettle, even if for non-standard non-deployed cases.

I'd personally prefer some kind of deprecation plan for those (even in the distant future is ok), so that they are uniformly rejected. Do you know of any other validator which understand those?
Comment 9 Wouter Wijngaards 2015-11-17 12:33:28 CET
Hi Luca,

Some might be lenient towards the wrongly encoded signatures.  I did not know they were in the testcases, to be honest.  I can try to remove the bad DSA formats from the tests.

Best regards, Wouter
Comment 10 Wouter Wijngaards 2015-11-17 13:38:41 CET
Hi Luca,

The "custom" DSA signatures are documented elsewhere in the code as being DER encoded signatures.  This means initial byte (T) and length are wrong.  Code calls (openssl) i2d_DSA_SIG() calls.  Somewhere it says 'bind format', so perhaps it was not only LDNS that was wrong.  I think the wrong signatures may be in ASN1.

Best regards, Wouter
Comment 11 Wouter Wijngaards 2015-11-17 13:49:33 CET
Hi Luca,

In secalgo.c:1570 you see the DSA sig with libNSS.  So, a DER parse when the length != 41.  I see der parsing calls in libnettle, but I don't know how to use them, is this easy for you to do?  (just extract the two bignums of the signature from the ASN; you do not have to validate the other asn goop).

Best regards, Wouter
Comment 12 Wouter Wijngaards 2015-11-17 14:22:53 CET
Hi Luca,

Never mind the previous message, got a patch that decodes DER with libnettle functions.  (They are not documented, but examples from code show how it's done).

Best regards, Wouter