DHX Incompatible with OpenSSL 3.0

[Windoze345]

I've built Netatalk 3 on Debian 12 Bookworm. Debian currently uses OpenSSL 3.0.9. Building and running works without problem but when i try to connect with a Mac OS 9.2.2 client I get the following error in the log: uams_dhx_pam.c :PAM: Err Generating Key (OpenSSL error code: 41943166, error:0280007E:Diffie-Hellman routines::modulus too small) The login fails after that.

As I understand it, this limit is hardcoded in OpenSSL >= 3.0 See this quote from the OpenSSL 3 migration guide:

Enforce a minimum DH modulus size of 512 bits Smaller sizes now result in an error.

Any ideas or workarounds?

[rdmark]

The workaround is to use LibreSSL rather than OpenSSL. DHX needs a 128 bit modulus size.

[rdmark]

Or, to disable DHX and use the clrtxt UAM for authentication with classic Mac OS. :)

[Windoze345]

Disabling DHX and enabling Clrtxt works for me. Maybe it would be nice to detect OpenSSl >= 3.0 at build time and don't build DHX then.

[rdmark]

That's an interesting option. I agree that it'd be good to have a default configuration that works out of the box. OTOH it wouldn't be very transparent to the user the criteria for when DHX is available and not.

Another, more brute-force, option that I could think of is to make the default afpd UAM configuration clrtxt+DHX2, rather than DHX+DHX2. It would be less secure, of course. But as an additional upside, this would make netatalk work out of the box with Mac OS 8 and earlier clients.

Yet another option is to make LibreSSL a dependency and use it by default over OpenSSL.

Thoughts?

[NJRoadfan]

LibreSSL isn't available as a package for most Linux distributions, particularly Debian and Ubuntu. There is also the possibility that 128bit key sizes will be dropped in the future with LibreSSL as well. On a related note, 2-way randnum UAMs still work fine on classic MacOS clients, despite being ancient and weak. The downside is that you need to maintain a afppasswd file.

[rdmark]

What I propose is that we make DHX2 the only UAM enabled by default on afpd runtime. Neither clrtxt nor randnum is secure at all so it seems prudent to keep the default configuration as secure as possible. https://github.com/Netatalk/netatalk/pull/359

What do you think?

[pbobbenb]

It isn't possible to bundle OpenSSL 1.1.1 so that it always has that version to compile against? That's what PHP, MySQL etc does, they have bundled several types of third party libraries (which isn't always the latest versions), so that it compiles against those versions first or you can select to compile with your own versions with a configure command. Then one wouldn't need to hunt down OpenSSL 1.1.1 on Ubuntu 22.04 f.ex. which doesn't have that version any longer, at least not the dev files readily available on apt.

[rdmark]

I do agree that this is an option. Thanks for suggesting it!

The primary argument against going down this path, is that it adds many lines of code to maintain, keep on top of security patches and manage hotfix releases etc. This project is already lacking in maintainer resources (I'm the only active one!) but if you or someone else would offer to help maintain the bundled openssl then I would consider it. :)

[pbobbenb]

Wouldn't it be rather easy to maintain openssl, since the 1.1.1 version is very soon EOL and will not receive any further updates/patches? And since most of us runs this for fun/hobby (I guess) and behind firewalls, how critical is it with security patches - at least with version 2.x? 3.x I guess is a slight bit more important with it running on several (if not all) major NAS'es, but that job should fall on the NAS vendors to do that job - if they are interested, right? After all they use it for free, at least they can/should give something back to the Netatalk community?

[rdmark]

I would personally not be comfortable distributing a piece of software with known security holes. In particular as long as major distros distribute a netatalk package. At least NetBSD is known to be distributing an up to date 2.2.x package.

FWIW the NAS vendors do contribute upstream patches every now and then, which is always appreciated. But it's hardly something that we have been able to rely on for fixing critical bugs in recent years. (As in: NAS folks has fixed some critical issues, but others remained open for a long time and were patched by other contributors.)

Now when you mention it though, I could try to reach out to them with an encouragement to do more. Do you know of NAS products that still actively distribute netatalk with their latest software?

BTW an option would be to bundle LibreSSL, which is actively developed but not always available as a package.

[pbobbenb]

Well, the only one I can say for sure is Synology, which has 3.1.12 in the latest DSM 7.1.1, which I have on my DS415play. https://www.synology.com/sv-se/dsm/feature/file_sharing

Browsing the web and it seems Qnap has AFP in the latest QTS 5.1, which I assume is Netatalk. https://docs.qnap.com/operating-system/qts/5.1.x/en-us/configuring-afp-apple-networking-settings-43EE210.html

Asustor also seem to have AFP in the latest ADM 4.x. https://www.asustor.com/en/applications/nas_for_apple_device

[ghost]

My take on this issue: I think a viable alternative to using OpenSSL or LibreSSL is to use WolfSSL.

https://github.com/wolfSSL/wolfssl

The great thing about WolfSSL is that is that is completely modular so only those modules required for DHX authentication need to be compiled. Hence it has a much smaller footprint. WolfSSL, like Netatalk, also uses GPL2.0 :)

I have added it as an additional library in libatalk on my fork, and it works great. This built-in approach future-proofs Netatalk against the ultimate and inevitable demise of DH support in mainstream OpenSSL (it is already marked as deprecated on OpenSSL3). Using DHX authentication in this current era will always pose a security risk on an open network, but if we assume that most Netatalk users are using it to file share with their vintage Macs running classic MacOS 9 and earlier then this risk is always being taken.

[rdmark]

@dgsga Are there any code modifications required to link netatalk against wolfssl? On macOS, are you using homebrew wolfssl packages, or are you bundling it with netatalk? Is there a minimum version of wolfssl required to use with netatalk?

My main concern is of course the cross-platform compatibility/support. I'll do some research on other supported OSes to find out if they distribute it. For starters: Debian does, and Ubuntu too of course.

[ghost]

@dgsga Are there any code modifications required to link netatalk against wolfssl? On macOS, are you using homebrew wolfssl packages, or are you bundling it with netatalk? Is there a minimum version of wolfssl required to use with netatalk?

My main concern is of course the cross-platform compatibility/support. I'll do some research on other supported OSes to find out if they distribute it. For starters: Debian does, and Ubuntu too of course.

Hi @rdmark, there are no code mods required (otand you can use either approach. You can either point --with-ssl-dir to a WolfSSL installation at configure time or you can embed a stripped down WolfSSL codebase into libatalk. On my fork I created a new library called libdhx to do just this, using only those files required for DHX authentication to work correctly. The reason I did this was to future-proof Netatalk (which is essentially now a legacy fileserver) against the possible removal of DHX support in the future in all flavours of SSL.

[ghost]

From the WolfSSL website:

Supported Operating Systems

One factor which defines wolfSSL is its ability to be easily ported to new platforms. As such, wolfSSL has support for a long list of operating systems out-of-the-box. Currently-supported operating systems include:

Win32/64 Linux Mac OS X Solaris ThreadX VxWorks FreeBSD NetBSD OpenBSD embedded Linux Yocto Linux OpenEmbedded WinCE Haiku OpenWRT iPhone (iOS) Android Nintendo Wii and Gamecube through DevKitPro QNX MontaVista NonStop TRON/ITRON/µITRON Micrium's µC/OS-III FreeRTOS SafeRTOS NXP/Freescale MQX Nucleus TinyOS HP/UX AIX ARC MQX TI-RTOS uTasker embOS INtime Mbed µT-Kernel RIOT CMSIS-RTOS FROSTED Green Hills INTEGRITY Keil RTX TOPPERS PetaLinux Apache Mynewt

[rdmark]

Hehe that's an impressive list. By "Solaris" I assume they mean Illumos distros. I had a quick look on OpenIndiana (April release) and its package manager didn't come with a binary package, but I guess building it from source should be straight forward.

[rdmark]

Hi @rdmark, there are no code mods required (otand you can use either approach. You can either point --with-ssl-dir to a WolfSSL installation at configure time or you can embed a stripped down WolfSSL codebase into libatalk. On my fork I created a new library called libdhx to do just this, using only those files required for DHX authentication to work correctly. The reason I did this was to future-proof Netatalk (which is essentially now a legacy fileserver) against the possible removal of DHX support in the future in all flavours of SSL.

For some reason it's not as easy on Debian. Their libwolfssl-dev package installs all the requisite libraries and headers under /usr but netatalk configure is being very stubborn and keep detecting the system openssl libraries. Perhaps it's a bug in the ssl-check.m4 macro.

[rdmark]

Notes on OpenSSL 1.1.1 ... It is still actively developed and new security releases posted. The latest being 1.1.1v last month. https://github.com/openssl/openssl/tree/OpenSSL_1_1_1-stable

The legal terms are iffy. Not ideal to burden netatalk with the dual license requirements of that code. https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/LICENSE

[rdmark]

Making some progress on linking with WolfSSL.

Unfortunately, it doesn't seem like WolfSSL's OpenSSL compatibility layer is compatible with the randnum UAM (and afppasswd) implementation. There are missing definitions for symbols f.e. in the des.h header (DES_KEY_SZ etc.)

@dgsga I see in your fork that you simply got rid of the randnum UAM... so I assume this was your solution to this problem?

[tom-cosgrove-arm]

it seems prudent to keep the default configuration as secure as possible

In modern cryptography 128-bit (non-elliptic curve) DH is considered insecure (e.g. see https://crypto.stackexchange.com/a/56006/50416 and https://github.com/openssl/openssl/issues/22158#issuecomment-1728591206)

[rdmark]

it seems prudent to keep the default configuration as secure as possible

In modern cryptography 128-bit (non-elliptic curve) DH is considered insecure (e.g. see https://crypto.stackexchange.com/a/56006/50416 and openssl/openssl#22158 (comment))

I agree completely. However in the absence of DHX, the only options for old Mac clients is either the "Randnum" UAM (roughly 56 bit encryption, no PAM integration) or "Cleartext" UAM (no encryption at all.) The way I see this is as a step up from no encryption at all, i.e. serving as obfuscation rather than comprehensive security. Just my 2c.

[ghost]

Making some progress on linking with WolfSSL.

Unfortunately, it doesn't seem like WolfSSL's OpenSSL compatibility layer is compatible with the randnum UAM (and afppasswd) implementation. There are missing definitions for symbols f.e. in the des.h header (DES_KEY_SZ etc.)

@dgsga I see in your fork that you simply got rid of the randnum UAM... so I assume this was your solution to this problem?

@rdmark, I just got rid of all insecure authentication methods that I never use on the macOS platform. Just kept DHX and DHX2, both with PAM.

[rdmark]

@dgsga Got it. We should consider removing the randnum UAM in the 3.x branch... Would allow us to remove the entire afppasswd suite as well. And makes a transition to wolfSSL's OpenSSL compatibility layer seamless.

The randnum UAM does have some value for System 7 and GS/OS clients, but we do still have the clrtxt fallback...

[NJRoadfan]

Given that Netatalk 3.x targets operating systems that support AFP3.0, deprecating anything older than DHX makes sense. Note that early System 7 requires AppleShare client updates to support TCP connections and GS/OS is limited to a hack (AFPBridge).

Another thing to consider is that AFP3 technically depreciated ProDOS metadata storage. The command was reused for Unicode file name support. Netatalk will still downgrade a connection to AFP2.x though, so System 7-9 and GS/OS still technically work. Somehow that code survived in the tree all these years.

[UUVE]

Since I too am unable to connect to a Netatalk 3.1.18 server from mac os 9 (UTM-Qemu virtual machine for now for testing, but I'm planning to connect to the Netatalk server from a real mac os 9 machine or Classic from Tiger Mac OS). I kindly ask for detailed instructions on how to compile netatalk with the wolfssl library. The use of plaintext passwords, aside from the security issues it poses, is not a viable alternative due to the limited clear text password length supported by Mac OS 9

[UUVE]

I forgot to mention some details. Netatalk runs on a debian "bookworm" server where the wolfssl library is available among the official debian packages

[rdmark]

@UUVE It's not that simple unfortunately. After my earlier attempt to link with it, I'm not confident the WolfSSL library packaged in Debian 12 has all the symbols that we need (although it could very well have been me messing something up.) The current plan is to eventually bundle a subset of WolfSSL with netatalk.

For a short-term solution: either downgrade to Debian 11 (to get OpenSSL 1.1 back) or run a Docker container to the same effect. Here's the "official" one that I made recently: https://hub.docker.com/r/netatalk/netatalk3

[UUVE]

@rdmark Thank you very much for your suggestions. I'm sorry that in my situation both solutions are not feasible. The Debian server has been running for a few years (updated and migrated several times from other machines starting from Appleshare IP!) and provides a number of services in addition to Netatalk (OpenlDap, Samba, etc.). Beyond that, it contains all the work I've produced from the early '90s to about 2010, with the various iterations of Mac OS Classic and Mac OS that I can't risk experimenting with. I look forward to a solution or other suggestions that resolve the Mac OS 9 connection issues. :) which is currently broken. The files contained on the server are essential for me to recover or reuse, as necessary, the work done during a career.

[rdmark]

@UUVE I would recommend you taking a backup of that data, first of all! It sounds quite important to you.

I still think Docker would be a perfect fit for your use case there. You can simply create bind mounts for your existing shared volumes and config files, to give you seamless migration to the containerized netatalk. I don’t think this would be more risky than rolling your own homebrew version of netatalk linked with wolfssl.

[ghost]

@rdmark, at the moment I have two different working options for using WolfSSL as DHX provider. First approach is to use WolfSSL as a dependency:

• Pros: Fewer code changes
• Cons: Support for DHX may be deprecated at some future point.

Second approach is to embed the necessary WolfSSL modules within an additional library (libdhx) within libatalk:

• Pros: DHX support is future-proofed
• Cons: Import of WolfSSL code into repo (WolfSSL uses the same GPL v2 license as Netatalk).

What do you think is the best way forwards?

[rdmark]

@dgsga Nicely done! The system dependency would be preferable in an ideal world, I think. In addition to your pro:

• Avoid committing to regularly maintaining 3rd party code when security patches / bugfixes are published.
• Debian doesn't allow packages to bundle a 3rd party library that is packaged elsewhere, so the package maintainer would have to make a big downstream patch to revert it. (Maybe other distros has similar policies.)

Did you investigate how common packaged wolfssl is in the various distros out there? With option 1, will users have to download wolfssl tarballs and built it themselves in many cases?

Did you get Random Number UAM working in parallel with DHX-powered-by-wolfssl? I assume we still need openssl or libressl for this one.

[rdmark]

This has been fixed for main (future v3.2) in https://github.com/Netatalk/netatalk/pull/965

https://github.com/Netatalk/netatalk/issues/980 has been created for backporting the same to 2.x

Closing this ticket as resolved.

[coffnix]

opensuse tumbleweed + libressl-devel works for me (server) :D

1- zypper in libressl libressl-devel 2- zypper in automake db-devel fdupes krb5-devel libacl-devel libavahi-devel libevent-devel libgcrypt-devel libtdb-devel libtool openldap2-devel libressl-devel pam-devel pkgconfig systemd tcpd-devel zlib-devel dbus-1-devel dbus-1-glib-devel tracker-devel rpm-build 3- build this spec: https://area31.net.br/downloads/netatalk.spec 4- rpmbuild -ba /usr/src/packages/SPECS/netatalk.spec

tested on macOS 9.2.2 on iMac G3 rev. A (client)

more infos:

English: https://area31.net.br/wiki/Restoring_a_1998_iMac_G3_rev_A

Brazilian Portuguese: https://area31.net.br/wiki/Revivendo_um_imac_G3_rev_A_de_1998

[coffnix]

update: I created a spec so you can easily compile Netatalk using DHCAST128 on openSUSE Linux. It’s new support utilizing embedded WolfSSL.

https://area31.net.br/downloads/netatalk-wolfssl.spec

work like a charm here :D

Sep 05 06:27:47.341667 afpd[11189] {uams_dhx2_pam.c:933} (debug:UAMS): DHX2: generating mersenne primes
Sep 05 06:27:47.449492 afpd[11189] {auth.c:106} (info:AFPDaemon): uam: "DHX2" available
Sep 05 06:27:47.449494 afpd[11189] {auth.c:106} (info:AFPDaemon): uam: "DHCAST128" available
Sep 05 06:27:55.430204 afpd[11307] {uams_dhx2_pam.c:328} (info:UAMS): DHX2 login: mac-server
Sep 05 06:27:55.457576 afpd[11307] {uams_dhx2_pam.c:213} (info:UAMS): PAM DHX2: PAM Success
Sep 05 06:27:55.508379 afpd[11307] {uams_dhx2_pam.c:708} (info:UAMS): DHX2: PAM Auth OK!

[rdmark]

Thanks for sharing! Please don't hesitate to add this information to https://github.com/Netatalk/netatalk/wiki/Installing-Netatalk-3-on-openSUSE

BTW, I would strongly recommend upgrading to the latest Netatalk version (currently 3.2.7) in your spec file.

[coffnix]

Thanks for sharing! Please don't hesitate to add this information to https://github.com/Netatalk/netatalk/wiki/Installing-Netatalk-3-on-openSUSE

BTW, I would strongly recommend upgrading to the latest Netatalk version (currently 3.2.7) in your spec file.

I will create a new spec with the updated version, thank you! Attached will be the screenshots of AFP working with Netatalk 3.2.0 authenticated via DHCAST128 on a 1998 iMac G3 Rev A. The client will be an original, unmodified MacOS 9.2.2, using SSLeavy/OpenSSL. :D

Congratulations on the excellent work with WolfSSL in Netatalk, and thank you very much for keeping my old imac G3 alive with a fully operational and functional network