Bug#976991: libldap-2.4-2:amd64: Please consider building with openssl instead of gnutls

[Matt Zagrabelny]

Package: libldap-2.4-2
Version: 2.4.56+dfsg-1
Severity: normal

Greetings,

I am using Debian's FreeRADIUS package (freeradius) and the corresponding LDAP
package (freeradius-ldap) to connect to an Active Directory (AD) server over ldaps
(TLS port 636).

Unfortunately FreeRADIUS is linked against openssl and cannot properly use
Debian's libldap-2.4-2, which is linked against gnutls, for TLS communication.

I've rebuilt openldap using openssl and have installed the resulting libldap-2.4-2
package. FreeRADIUS is now able to communicate with AD and my FreeRADIUS setup is
able to correctly communicate with AD (LDAP).

From what I understand Fedora is building openldap with openssl.

If the licensing is a concern (due to OpenLDAP's license), Debian now considers openssl
to be a system library.

Thank you for considering this change.

-m

-- System Information:
Debian Release: bullseye/sid
APT prefers oldoldstable
APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libldap-2.4-2:amd64 depends on:
ii libc6 2.29-10
ii libsasl2-2 2.1.27+dfsg-2
ii libssl1.1 1.1.1d-2

Versions of packages libldap-2.4-2:amd64 recommends:
ii libldap-common 2.4.49+dfsg-2

libldap-2.4-2:amd64 suggests no packages.

-- no debconf information

[Steve Langasek]

On Wed, Dec 09, 2020 at 01:07:11PM -0600, Matt Zagrabelny wrote:
> Unfortunately FreeRADIUS is linked against openssl and cannot properly use
> Debian's libldap-2.4-2, which is linked against gnutls, for TLS
> communication.

Independent of questions of whether openldap should switch to openssl, could
you elaborate why FreeRADIUS being linked against openssl causes a problem
for a module linked against gnutls? The two implementations should be
entirely independent and able to operate independently within the same
process.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slan...@ubuntu.com vor...@debian.org

[Matt Zagrabelny]

On Wed, Dec 9, 2020 at 1:45 PM Steve Langasek <vor...@debian.org> wrote:

On Wed, Dec 09, 2020 at 01:07:11PM -0600, Matt Zagrabelny wrote:
> Unfortunately FreeRADIUS is linked against openssl and cannot properly use
> Debian's libldap-2.4-2, which is linked against gnutls, for TLS
> communication.

Independent of questions of whether openldap should switch to openssl, could
you elaborate why FreeRADIUS being linked against openssl causes a problem
for a module linked against gnutls?  The two implementations should be
entirely independent and able to operate independently within the same
process.

I agree. It should work. Why it doesn't...

Short answer. I don't know.

Medium answer: Upstream states that gnutls claims to be compatible with openssl, but it isn't compatible. If you search the net for "Alan DeKok openssl gnutls ldap" you'll get hits.

Long guessing answer: Perhaps the FR LDAP module (rlm_ldap) makes library calls that it expects to behave a certain way. If gnutls is providing those function endpoints, it might be failing because the module (rlm_ldap) is using openssl specific semantics.

I can confirm empirically that FR using libldap* works when openldap is built with openssl and fails when libldap* uses gnutls. It fails at the TLS layer - that is, the TLS connection fails.

I would wager that upstream has no interest in modifying its code to work with gnutls (or Mozilla NSS).

-m

[Ryan Tandy]

Control: severity -1 wishlist

Hi Matt,

On Wed, Dec 09, 2020 at 01:07:11PM -0600, Matt Zagrabelny wrote:

>Unfortunately FreeRADIUS is linked against openssl and cannot properly use
>Debian's libldap-2.4-2, which is linked against gnutls, for TLS communication.

I'm missing a lot of context here. Why does libldap's TLS library matter
to freeradius? Is there a bug against freeradius I should read?

>From what I understand Fedora is building openldap with openssl.
>
>If the licensing is a concern (due to OpenLDAP's license), Debian now considers openssl
>to be a system library.
>
>Thank you for considering this change.

For avoidance of doubt: I would rather not consider it for bullseye at
this point, as the freeze is beginning soon. For bookworm it's
definitely a possibility.

I have indeed heard that we consider openssl to be a system library now,
and a couple of people pointed out that it's no longer mentioned in
ftp-master's REJECT-FAQ. On the other hand at least one person has
raised concerns[1] about whether it's a valid approach.

The main concern for me is a painful transition for users. The
TLSCipherSuite setting is completely incompatible between the two
(OpenSSL cipher lists and GnuTLS priority strings have completely
different syntax) and the last time this was changed, there were bugs
being reported about it for a long time afterward[2][3]. There are also
some other, smaller differences in how they handle certificates[4] and
probably other things.

When Red Hat transitioned from NSS to OpenSSL, they wrote an entire
TLS shim module (tls_mc) to provide backward compatibility with existing
NSS setups. Not sure if we'd actually need that much support, but that's
to give you an idea of the amount of effort they considered justified.

I'm not saying the upgrade pain needs to block a transition, only that
the benefits of the transition need to outweigh the pain, and that we
need a better upgrade story than "oh btw your slapd/sssd/etc doesn't
start anymore".

cheers,
Ryan

[1] https://lists.debian.org/debian-devel/2020/10/msg00168.html
[2] https://bugs.debian.org/541256
[3] https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1103353/comments/19
[4] https://bugs.openldap.org/show_bug.cgi?id=8586#c6

[Quanah Gibson-Mount]

I read over the source of the rlm_ldap module and the freeradius
src/lib/ldap code, and it does specifically require functionality that's
only implemented for OpenSSL inside of libldap (such as the TLS Min
protocol) that are ignored for GnuTLS.

So for freeradius to work with a GnuTLS compiled libldap would require
modifying the freeradius source code accordingly, which may be a bit of
work. It also seems unlikely the freeradius project would be interested in
taking any such work back as they are only implementing on OpenSSL.

The best solution long term may simply be to switch to OpenSSL for OpenLDAP
starting with the 2.5 release series in Debian.

Regards,
Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>

[Matt Zagrabelny]

On Wed, Dec 9, 2020 at 2:23 PM Ryan Tandy <ry...@nardis.ca> wrote:


> I have indeed heard that we consider openssl to be a system library now,
> and a couple of people pointed out that it's no longer mentioned in
> ftp-master's REJECT-FAQ. On the other hand at least one person has
> raised concerns[1] about whether it's a valid approach.

I'm not familiar with the OpenLDAP Public License. Is it compatible
with Apache v2 license? That is the license for openssl v3.

>
> The main concern for me is a painful transition for users. The
> TLSCipherSuite setting is completely incompatible between the two
> (OpenSSL cipher lists and GnuTLS priority strings have completely
> different syntax) and the last time this was changed, there were bugs
> being reported about it for a long time afterward[2][3].

From [2]:

Howard Chu <h...@openldap.org> on Thu, 13 Aug 2009 11:15:48 -0700
"""
As software and security professionals, we cannot in good conscience stand
mute on the subject. The quality of the code in GnuTLS is obviously low, the
risk of security vulnerabilities is high, and the cost in maintenance is only
going up. Whether you want to hear it or not, we are obligated to state for
the record that using GnuTLS is a bad idea, because that's the objective truth.
"""

I don't know if that opinion holds any weight, but I'd consider the
freeradius ldap module (in package freeradius-ldap) broken due to the
openssl TLS specific code that FR uses.

Any traction on a gnutls -> openssl migration for openldap for bookworm?

Thanks for any info.

-m

[Ryan Tandy]

On Wed, Feb 02, 2022 at 12:53:59PM -0600, Matt Zagrabelny wrote:
>Any traction on a gnutls -> openssl migration for openldap for bookworm?

I don't have any technical reasons to block it, but for personal reasons
I'm not likely to pursue it myself.

As already written in the RFH bug (#512360), I'm already trying to get
out of maintaining this package, and I'm really not keen on taking on
additional support burden by breaking working TLS setups. If someone
would join the team as co-maintainer and commit to helping with upgrades
and user support for bookworm, that would help a lot. As it stands, I'm
not enthusiastic about pursuing a breaking change like this by myself.

[John Scott]

A lot of arguments have been made for switching to OpenSSL, and I can think of some arguments that haven't even been made yet. I just wrote two OpenLDAP autopkgtests that interact with other packages to prove my merit as a knowledgeable contributor, even if I did just learn today the majority of what I know.

Debian Experimental is currently at the latest upstream release which is awesome. I think we should seize this opportunity and start staging changes in Experimental. I'll write some TLS autopkgtests, we'll rebuild reverse dependencies and see how they fare, it'll be great.

If you want me to make these changes, I can prepare a Merge Request keeping them small. But I think someone who is more familiar with OpenLDAP besides libldap (my forte) should do that.

[Ryan Tandy]

On Wed, Jul 26, 2023 at 09:54:16AM +0000, John Scott wrote:
>I'll write some TLS autopkgtests, we'll rebuild reverse dependencies
>and see how they fare, it'll be great.

That's an excellent first step, thanks for looking into it!

Regarding staging in experimental, Sergio currently uses that for
merging new upstream versions into Ubuntu. Not raising that as a blocker
per se, just to be aware that coordination might be appreciated.

I don't really expect issues with reverse dependencies. It'll be good to
confirm, but I'd be surprised if any users of the library have
significant issues. The things that really concern me are:

- does changing the TLS backend affect the ABI of libldap, requiring a
library transition (it "shouldn't", but sometimes things leak
unintentionally)

- determining how upgrades work for people who currently use
TLSCipherSuite or the equivalent slapd settings, and supporting them
through the transition (before and after trixie's release)

Thanks for taking steps to move this forward!

[Sergio Durigan Junior]

On Wednesday, July 26 2023, Ryan Tandy wrote:

> On Wed, Jul 26, 2023 at 09:54:16AM +0000, John Scott wrote:
>> I'll write some TLS autopkgtests, we'll rebuild reverse dependencies
>> and see how they fare, it'll be great.
>
> That's an excellent first step, thanks for looking into it!

+1, thanks for helping with this, John.

> Regarding staging in experimental, Sergio currently uses that for
> merging new upstream versions into Ubuntu. Not raising that as a
> blocker per se, just to be aware that coordination might be
> appreciated.

Thank you, Ryan.

Indeed, I have been using the version on experimental as a base for
Ubuntu's OpenLDAP package. I am more than willing to help with the
switch and sponsor uploads to experimental, though. I usually need to
perform Ubuntu merges once per cycle (i.e., every six months), so we can
work on the switch during these intervals.

Thanks,

--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/

[John Scott]

On Thu, 2023-07-27 at 12:25 -0400, Sergio Durigan Junior wrote:
> > > I'll write some TLS autopkgtests, we'll rebuild reverse dependencies
> > > and see how they fare, it'll be great.
> >
> > That's an excellent first step, thanks for looking into it!
>
> +1, thanks for helping with this, John.

Thank you for your encouragement! I have sent a merge request here that checks that TLS works, it should work without change for GnuTLS and OpenSSL:
https://salsa.debian.org/openldap-team/openldap/-/merge_requests/8

Note that this only uses TLS for the server-side (what most people think of when they think of TLS), the test could be extended to test client certificates too I suppose but let's do one thing at a time.

I know you just made an upload, obviously there's no hurry to get this in the archive.

I like that working on this package forces me to learn about LDAP one step at a time. If now is not a good time to stage the OpenSSL switch, please let me know if there is other low-hanging fruit to work on. I'm sure you saw my announcement email that I'm putting together an LDAP CURL autopkgtest, and am happy to report that I've also prepared an autopkgtest testing that gpgsm can fetch S/MIME certificates over LDAP. Yay, I love autopkgtests!