DHX Incompatible with OpenSSL 3.0 #358
Comments
|
The workaround is to use LibreSSL rather than OpenSSL. DHX needs a 128 bit modulus size. |
|
Or, to disable DHX and use the clrtxt UAM for authentication with classic Mac OS. :) |
|
Disabling DHX and enabling Clrtxt works for me. |
|
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? |
|
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. |
|
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. #359 What do you think? |
|
It isn't possible to bundle OpenSSL 1.1.1 so that it always has that version to compile against? |
|
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. :) |
|
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? |
|
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. |
|
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. Browsing the web and it seems Qnap has AFP in the latest QTS 5.1, which I assume is Netatalk. Asustor also seem to have AFP in the latest ADM 4.x. |
|
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. |
|
@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. |
|
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 |
|
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. |
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. |
|
Notes on OpenSSL 1.1.1 ... The legal terms are iffy. Not ideal to burden netatalk with the dual license requirements of that code. |
|
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 @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? |
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. |
@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. |
|
@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... |
|
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. |
|
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 |
|
I forgot to mention some details. Netatalk runs on a debian "bookworm" server where the wolfssl library is available among the official debian packages |
|
@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 |
|
@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. |
|
@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:
Second approach is to embed the necessary WolfSSL modules within an additional library (libdhx) within libatalk:
What do you think is the best way forwards? |
|
@dgsga Nicely done! The system dependency would be preferable in an ideal world, I think. In addition to your pro:
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. |
|
opensuse tumbleweed + libressl-devel works for me (server) :D 1- zypper in libressl libressl-devel tested on macOS 9.2.2 on iMac G3 rev. A (client) more infos: https://area31.net.br/wiki/Revivendo_um_imac_G3_rev_A_de_1998#Rede_AFP_para_troca_de_arquivos (translate to your language) |
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:
Any ideas or workarounds?
The text was updated successfully, but these errors were encountered: