Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement support for DANE using the gnutls-dane library #121

Open
wants to merge 3 commits into
base: master
from

Conversation

Projects
None yet
5 participants
@nomis
Copy link
Contributor

nomis commented Jul 6, 2014

I've only added this to configure.ac, so it will require additional changes to work with CMake.

This can be used on Gentoo as-is, or on Debian Jessie/Ubuntu Utopic if gnutls28 is modified to provide gnutls-dane.

nomis added some commits Jul 6, 2014

core: implement support for DANE
Use gnutls-dane to obtain DANE TLSA records on SSL connections.

Performs a synchronous DNS lookup to get TLSA data between the
normal DNS resolve and the TCP connect.
irc: implement support for DANE
Use gnutls-dane to check DANE TLSA records on SSL connections.

Performs a check of the cached TLSA data when verifying the
certificate.

@flashcode flashcode added this to the 1.1 milestone Jul 8, 2014

@flashcode flashcode self-assigned this Jul 11, 2014

@kyrias

This comment has been minimized.

Copy link

kyrias commented Sep 18, 2014

Is there anything more than the CMake part of this that's missing?

@nomis

This comment has been minimized.

Copy link
Contributor Author

nomis commented Oct 5, 2014

No, it's all functional. You'd need to replicate the same version check logic in CMake, some of the older GnuTLS releases have severe flaws in their behaviour.

There should be a copy of weechat__dane_query_to_raw_tlsa() named dane_query_to_raw_tlsa() in a future release of GnuTLS that you could opt to use instead if you increase the minimum version requirements.

GnuTLS still has this outstanding bug if CA type TLSA records are used: http://savannah.gnu.org/support/?108552

@flashcode

This comment has been minimized.

Copy link
Member

flashcode commented Oct 15, 2014

Is it possible to test that with GnuTLS version currently in Debian unstable?

@nomis

This comment has been minimized.

Copy link
Contributor Author

nomis commented Oct 15, 2014

Yes but you'll need to modify the gnutls28 package to create libgnutls-dane0.

Debian aren't going to support gnutls-dane until GnuTLS stops linking against Unbound or Unbound doesn't depend on OpenSSL: http://lists.gnutls.org/pipermail/gnutls-devel/2014-February/006793.html

@flashcode flashcode modified the milestones: 1.1, 1.2 Dec 21, 2014

@nomis

This comment has been minimized.

Copy link
Contributor Author

nomis commented Jan 18, 2015

This could wait until GnuTLS 3.4 which will drop the libunbound dependency in favour of assuming a local validating resolver. Such a change may result in libgnutls-dane being merged into libgnutls.

http://lists.gnutls.org/pipermail/gnutls-devel/2014-July/007039.html
https://www.gitorious.org/gnutls/pages/Plan3_4

However, the discussions on how to configure support for this in glibc appear to have stalled: https://sourceware.org/ml/libc-alpha/2014-06/msg00586.html

@Mikaela

This comment has been minimized.

Copy link
Contributor

Mikaela commented Oct 18, 2015

It looks like the issue has moved to GnuTLS 3.5 now and the issue is at https://gitlab.com/gnutls/gnutls/issues/21.

@nmav

This comment has been minimized.

Copy link

nmav commented Nov 20, 2017

I'm not sure how the gnutls issue 21 blocks that feature. gnutls already provides a DANE back-end, whether that's linked with unbound or something else shouldn't block its use of it by weechat.

@nomis

This comment has been minimized.

Copy link
Contributor Author

nomis commented Nov 20, 2017

At the time this was raised, libunbound depended on openssl, which is absurd for gnutls to link to.

This has now been fixed: https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=594

@Mikaela

This comment has been minimized.

Copy link
Contributor

Mikaela commented Nov 20, 2017

This has now been fixed: https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=594

Does this mean that this can finally be merged (after merge conflicts are resolved)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.