Firefox 144 now uses AES-256-CBC instead of 3DES-CBC

[jrw]

As of sometime around Oct 1, 2025, Firefox now uses a different encryption algorithm, so firefox_decrypt.py no longer works.

To reproduce, just attempt to run against a version of Firefox >= 144. I get: ERROR - Username/Password decryption failed. Credentials damaged or cert/key file mismatch.

Linux Mint 21.3 (Virginia) 64 bits Firefox 144.0.2 Python 3.10.12 firefox_decrypt.py 1.1.1+git

[unode]

@jrw thanks for the report! I haven't tested with the latest Firefox version.

Can you try to install NSS version 3.113 or newer? AES support was supposedly introduced in this libnss version.

The discussion about missing AES support took place here.

[jrw]

On my system, I see 3 different versions of NSS under /usr/lib:

/usr/lib/firefox/libnss3.so
/usr/lib/thunderbird/libnss3.so
/usr/lib/x86_64-linux-gnu/libnss3.so

If I run LD_LIBRARY_PATH=/usr/lib/firefox firefox_decrypt.py then I am able to decrypt my firefox passwords. However, using the other two directories for LD_LIBRARY_PATH fails, as I described in the issue.

Under /etc/ld.so.conf.d/, I have:

/etc/ld.so.conf.d/fakeroot-x86_64-linux-gnu.conf:
/usr/lib/x86_64-linux-gnu/libfakeroot

/etc/ld.so.conf.d/i386-linux-gnu.conf:
# Multiarch support
/usr/local/lib/i386-linux-gnu
/lib/i386-linux-gnu
/usr/lib/i386-linux-gnu
/usr/local/lib/i686-linux-gnu
/lib/i686-linux-gnu
/usr/lib/i686-linux-gnu

/etc/ld.so.conf.d/libc.conf:
# libc default configuration
/usr/local/lib

/etc/ld.so.conf.d/x86_64-linux-gnu.conf:
# Multiarch support
/usr/local/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

So, I'm guessing that the call to ct.CDLL(nsslib) in the firefox_decrypt.py code on line 237, where the value of nsslib is "libnss3.so" looks to be using /usr/lib/x86_64-linux-gnu/libnss3.so, which apparently doesn't support choosing the encryption algorithm from the encrypted blob itself.

In any case, I have my work-around. Thanks for getting me pointed in the right direction for that!

[unode]

Yes, it looks like you may have some libs that are compatible with the new encryption (those bundled with Firefox) and some that aren't (nss installed system-wide). The latter was probably being loaded first.

I also notice from your logs that your bundled libs live in /usr/lib/firefox and /usr/lib/thunderbird. Currently firefox_decrypt checks only /usr/lib and not subfolders so this is something we can improve.

Thanks for the detailed report!

[unode]

Can you check if 7d86cb29693085934c43c7e11e210516a13baeb9 works for you without the LD_LIBRARY_PATH override?

[jrw]

I can check, but it will have to wait for a week+ as I'm going out of town this morning.

[pepa65]

Can you check if 7d86cb2 works for you without the LD_LIBRARY_PATH override?

For me this doesn't work, relevant part of the debug:

2025-11-07 10:31:57,187 - INFO - Running firefox_decrypt version: 1.1.1+git
2025-11-07 10:31:57,187 - DEBUG - Parsed commandline arguments: Namespace(profile='~/.mozilla/firefox', format=<class '__main__.HumanOutputFormat'>, csv_delimiter=';', csv_quotechar='"', csv_header=True, pass_username_prefix='', pass_prefix='web', pass_cmd='pass', pass_always_with_login=False, interactive=True, non_fatal_decryption=False, choice=None, list=False, encoding='utf-8', verbose=2)
2025-11-07 10:31:57,188 - DEBUG - Running with encodings: stdin: utf-8, stdout: utf-8, stderr: utf-8, locale: UTF-8
2025-11-07 10:31:57,188 - DEBUG - Loading NSS library from firefox/libnss3.so
2025-11-07 10:31:57,188 - DEBUG - Loading NSS library from thunderbird/libnss3.so
2025-11-07 10:31:57,188 - DEBUG - Loading NSS library from libnss3.so
2025-11-07 10:31:57,188 - DEBUG - Loaded NSS library from libnss3.so

It seems to still prefer to use the OS's NSS library over the firefox one (which is the only one that works).

• Linux Mint 22.2
• python 3.12.3-0ubuntu2
• firefox 144.0.2+linuxmint1+zara
• NSS_3.79 listed as latest for /usr/lib/x86_64-linux-gnu/libnss3.so (while /usr/lib/firefox/libnss3.so has NSS_3.116)

[jrw]

It doesn't work for me either (the LD_LIBRARY_PATH workaround still works however):

$ ./firefox_decrypt.py -vv
2025-11-10 01:42:54,454 - INFO - Running firefox_decrypt version: 1.1.1-6-g7d86cb2
2025-11-10 01:42:54,454 - DEBUG - Parsed commandline arguments: Namespace(profile='~/.mozilla/firefox', format=<class '__main__.HumanOutputFormat'>, csv_delimiter=';', csv_quotechar='"', csv_header=True, pass_username_prefix='', pass_prefix='web', pass_cmd='pass', pass_always_with_login=False, interactive=True, non_fatal_decryption=False, choice=None, list=False, encoding='utf-8', verbose=2)
2025-11-10 01:42:54,454 - DEBUG - Running with encodings: stdin: utf-8, stdout: utf-8, stderr: utf-8, locale: UTF-8
2025-11-10 01:42:54,454 - DEBUG - Loading NSS library from firefox/libnss3.so
2025-11-10 01:42:54,454 - DEBUG - Loading NSS library from thunderbird/libnss3.so
2025-11-10 01:42:54,454 - DEBUG - Loading NSS library from libnss3.so
2025-11-10 01:42:54,455 - DEBUG - Loaded NSS library from libnss3.so
2025-11-10 01:42:54,455 - DEBUG - Reading profiles from /home/..../.mozilla/firefox/profiles.ini
2025-11-10 01:42:54,455 - DEBUG - Read profiles ['Profile0', 'Install4F96D1932A9F858E', 'Install6230AD9FB497EC11', 'General']
2025-11-10 01:42:54,455 - DEBUG - Initializing NSS with profile 'sql:/home/..../.mozilla/firefox/.....default-release'
2025-11-10 01:42:54,457 - DEBUG - Initializing NSS returned 0
2025-11-10 01:42:54,457 - DEBUG - Retrieving internal key slot
2025-11-10 01:42:54,457 - DEBUG - Internal key slot <__main__.LP_PK11SlotInfo object at 0x7f9c53f56bc0>

Primary Password for profile /home/..../.mozilla/firefox/.....default-release:
2025-11-10 01:42:58,380 - DEBUG - Authenticating with password '....'
2025-11-10 01:42:58,398 - DEBUG - Checking user password returned 0
2025-11-10 01:42:58,398 - DEBUG - Database location: /home/..../.mozilla/firefox/.....default-release/logins.json
2025-11-10 01:42:58,398 - INFO - Using /home/..../.mozilla/firefox/.....default-release/logins.json for credentials.
2025-11-10 01:42:58,398 - INFO - Decrypting credentials
2025-11-10 01:42:58,398 - DEBUG - Reading password database in JSON format
2025-11-10 01:42:58,399 - DEBUG - Decrypting username data '....'
2025-11-10 01:42:58,426 - DEBUG - Decryption of data returned -1
2025-11-10 01:42:58,426 - ERROR - Username/Password decryption failed. Credentials damaged or cert/key file mismatch.
2025-11-10 01:42:58,426 - DEBUG - SEC_ERROR_INVALID_KEY: The key does not support the requested operation.

[unode]

(...)
2025-11-10 01:42:54,455 - DEBUG - Loaded NSS library from libnss3.so
(...)

This indicates that it is using the libnss3.so installed system-wide (likely /usr/lib/ or /usr/lib64) and that version is too old and doesn't support the new algorithm.

Where are you pointing your LD_LIBRARY_PATH to?

[unode]

I think I see where the issue might be coming from. One extra setting was still giving priority to the system-wide lib.

Can you both check if the changes introduced in https://github.com/unode/firefox_decrypt/commit/91144708394b72865cbedd0d715f0435e06a8af8 fix it for you?

[unode]

The lib finding machinery is now very error-prone. We'll need to make the process smarter by reading both the DB and the lib information and rejecting the combination if the two aren't compatible.

Hopefully the last workaround gives us some more time but it looks like a partial rewrite is in the horizon. If any of you would be interested in contributing, I would appreciate the help as I don't see myself finding the time anytime soon.

[jrw]

It looks like its still not finding it without LD_LIBRARY_PREFIX:

2025-11-10 14:43:47,795 - INFO - Running firefox_decrypt version: 1.1.1-9-g9114470
2025-11-10 14:43:47,795 - DEBUG - Parsed commandline arguments: Namespace(profile='~/.mozilla/firefox', format=<class '__main__.HumanOutputFormat'>, csv_delimiter=';', csv_quotechar='"', csv_header=True, pass_username_prefix='', pass_prefix='web', pass_cmd='pass', pass_always_with_login=False, interactive=True, non_fatal_decryption=False, choice=None, list=False, encoding='utf-8', verbose=2)
2025-11-10 14:43:47,795 - DEBUG - Running with encodings: stdin: utf-8, stdout: utf-8, stderr: utf-8, locale: UTF-8
2025-11-10 14:43:47,795 - DEBUG - Loading NSS library from ./firefox/libnss3.so
2025-11-10 14:43:47,796 - DEBUG - Loading NSS library from ./thunderbird/libnss3.so
2025-11-10 14:43:47,796 - DEBUG - Loading NSS library from ./libnss3.so
2025-11-10 14:43:47,796 - DEBUG - Loading NSS library from /usr/lib64/firefox/libnss3.so
2025-11-10 14:43:47,796 - DEBUG - Loading NSS library from /usr/lib64/thunderbird/libnss3.so
2025-11-10 14:43:47,796 - DEBUG - Loading NSS library from /usr/lib64/libnss3.so
2025-11-10 14:43:47,796 - DEBUG - Loading NSS library from /usr/lib64/nss/firefox/libnss3.so
2025-11-10 14:43:47,796 - DEBUG - Loading NSS library from /usr/lib64/nss/thunderbird/libnss3.so
2025-11-10 14:43:47,796 - DEBUG - Loading NSS library from /usr/lib64/nss/libnss3.so
2025-11-10 14:43:47,796 - DEBUG - Loading NSS library from /usr/lib/firefox/libnss3.so
2025-11-10 14:43:47,796 - DEBUG - Loading NSS library from /usr/lib/thunderbird/libnss3.so
2025-11-10 14:43:47,797 - DEBUG - Loading NSS library from /usr/lib/libnss3.so
2025-11-10 14:43:47,797 - DEBUG - Loading NSS library from /usr/lib/nss/firefox/libnss3.so
2025-11-10 14:43:47,797 - DEBUG - Loading NSS library from /usr/lib/nss/thunderbird/libnss3.so
2025-11-10 14:43:47,797 - DEBUG - Loading NSS library from /usr/lib/nss/libnss3.so
2025-11-10 14:43:47,797 - DEBUG - Loading NSS library from /usr/local/lib/firefox/libnss3.so
2025-11-10 14:43:47,797 - DEBUG - Loading NSS library from /usr/local/lib/thunderbird/libnss3.so
2025-11-10 14:43:47,797 - DEBUG - Loading NSS library from /usr/local/lib/libnss3.so
2025-11-10 14:43:47,797 - DEBUG - Loading NSS library from /usr/local/lib/nss/firefox/libnss3.so
2025-11-10 14:43:47,797 - DEBUG - Loading NSS library from /usr/local/lib/nss/thunderbird/libnss3.so
2025-11-10 14:43:47,797 - DEBUG - Loading NSS library from /usr/local/lib/nss/libnss3.so
2025-11-10 14:43:47,797 - DEBUG - Loading NSS library from /opt/local/lib/firefox/libnss3.so
2025-11-10 14:43:47,797 - DEBUG - Loading NSS library from /opt/local/lib/thunderbird/libnss3.so
2025-11-10 14:43:47,797 - DEBUG - Loading NSS library from /opt/local/lib/libnss3.so
2025-11-10 14:43:47,797 - DEBUG - Loading NSS library from /opt/local/lib/nss/firefox/libnss3.so
2025-11-10 14:43:47,797 - DEBUG - Loading NSS library from /opt/local/lib/nss/thunderbird/libnss3.so
2025-11-10 14:43:47,797 - DEBUG - Loading NSS library from /opt/local/lib/nss/libnss3.so
2025-11-10 14:43:47,797 - DEBUG - Loading NSS library from /home/..../.nix-profile/lib/firefox/libnss3.so
2025-11-10 14:43:47,797 - DEBUG - Loading NSS library from /home/..../.nix-profile/lib/thunderbird/libnss3.so
2025-11-10 14:43:47,798 - DEBUG - Loading NSS library from /home/..../.nix-profile/lib/libnss3.so
2025-11-10 14:43:47,798 - DEBUG - Loading NSS library from firefox/libnss3.so
2025-11-10 14:43:47,798 - DEBUG - Loading NSS library from thunderbird/libnss3.so
2025-11-10 14:43:47,798 - DEBUG - Loading NSS library from libnss3.so
2025-11-10 14:43:47,798 - DEBUG - Loaded NSS library from libnss3.so

[jrw]

Your code doesn't show the exception that's coming back when it tries to load /usr/lib/firefox/libnss3.so, but I added a line of code to show it: /lib/x86_64-linux-gnu/libnssutil3.so: version `NSSUTIL_3.101' not found (required by /usr/lib/firefox/libnss3.so) So, nss: ct.CDLL = ct.CDLL(nsslib) is getting that exception when nsslib is /usr/lib/firefox/libnss3.so, but somehow later on when loading libnss3.so from the systemwide library path (augmented by LD_LIBRARY_PATH) it is able to succeed without an exception.

[pepa65]

Why can't you just always use the Firefox nsslib? That is the one that encrypted them in the first place. It would be nice if there is an option to always use LD_LIBRARY_PATH=/usr/lib/firefox by specifying it in the code so users don't have to prefix the command with it.

[jrw]

Unfortunately, LD_LIBRARY_PATH is non-operative (except for child processes) if it is set in the code, unless the code re-execs itself. LD_LIBRARY_PATH must be set properly before the python interpreter is run. But I do agree that it would be best to use the library that firefox is using if that can be determined.

[unode]

/lib/x86_64-linux-gnu/libnssutil3.so: version `NSSUTIL_3.101' not found (required by /usr/lib/firefox/libnss3.so)

This is a similar problem to #98 . Chained dependencies.

@jrw is correct in that LD_LIBRARY_PATH is a workaround, not a solution.

Why can't you just always use the Firefox nsslib?

There's a lot of history here. The short story is that Python, Firefox and other system libs need to be compatible for everything to work. On top of this, firefox_decrypt supports the 3 main OSes which have slightly different quirks to them. The libnssutil3.so dependency mentioned above is one example.

[unode]

@jrw do you have /usr/lib/firefox/libnssutil3.so in your system? If yes, could you try the following change:

--- firefox_decrypt.py	2025-11-10 19:22:05.764957104 +0100
+++ firefox_decrypt_new.py	2025-11-11 19:38:53.750306412 +0100
@@ -211,7 +211,7 @@
     """Locate nss is one of the many possible locations"""
     fail_errors: list[tuple[str, str]] = []

-    OS = ("Windows", "Darwin")
+    OS = ("Windows", "Darwin", "Linux")
     sublocations = ("firefox", "thunderbird", "")

     for loc in locations:

and let me know if it helps?

I haven't yet been able to replicate this on my system...

[unode]

PS: I'll try to add a test profile for Firefox 144 which will hopefully make it easier to test.

[jrw]

Adding more debugging didn't really help. I do have /usr/lib/firefox/libnssutil3.so.
However:

$ ldd /usr/lib/firefox/libnss3.so
/usr/lib/firefox/libnss3.so: /lib/x86_64-linux-gnu/libnssutil3.so: version `NSSUTIL_3.101' not found (required by /usr/lib/firefox/libnss3.so)
	linux-vdso.so.1 (0x00007ffe5358b000)
	libnspr4.so => /lib/x86_64-linux-gnu/libnspr4.so (0x00007fe014336000)
	libplc4.so => /lib/x86_64-linux-gnu/libplc4.so (0x00007fe01432f000)
	libplds4.so => /lib/x86_64-linux-gnu/libplds4.so (0x00007fe01432a000)
	libnssutil3.so => /lib/x86_64-linux-gnu/libnssutil3.so (0x00007fe0142f7000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe0142f2000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe0142ed000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe0140c2000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fe01445c000)

But:

$ LD_LIBRARY_PATH=/usr/lib/firefox ldd /usr/lib/firefox/libnss3.so
	linux-vdso.so.1 (0x00007ffddf188000)
	libnspr4.so => /usr/lib/firefox/libnspr4.so (0x00007f37732a4000)
	libplc4.so => /usr/lib/firefox/libplc4.so (0x00007f377329d000)
	libplds4.so => /usr/lib/firefox/libplds4.so (0x00007f3773297000)
	libnssutil3.so => /usr/lib/firefox/libnssutil3.so (0x00007f3773264000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3773244000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f377323d000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3773014000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f37733aa000)

So, it looks to me like firefox itself must do the equivalent of setting LD_LIBRARY_PATH before loading libnss3.so to get it successfully loaded (or load /usr/lib/firefox/libnssutil3.so directly using dlopen?). @unode Assuming you're running some linux distribution, what do you see for the output of ldd? (Why aren't you hitting the same issue as me?)

[pepa65]

• OS = ("Windows", "Darwin", "Linux")

Doesn't help...

[pepa65]

libnspr4.so => /usr/lib/firefox/libnspr4.so (0x00007f37732a4000) libplc4.so => /usr/lib/firefox/libplc4.so (0x00007f377329d000) libplds4.so => /usr/lib/firefox/libplds4.so (0x00007f3773297000) libnssutil3.so => /usr/lib/firefox/libnssutil3.so (0x00007f3773264000)

Maybe if firefox_decrypt.py can also load libnspr4.so, libplc4.so, libplds4.so and libnssutil3.so from the same location it would work?

EDIT: Inserting this code into the __init__ of class NSSProxy and removing the line self.libnss = load_libnss() makes it work for me:

self.libnss1 = ct.CDLL("/usr/lib/firefox/libnspr4.so", mode=ct.RTLD_GLOBAL)
self.libnss2 = ct.CDLL("/usr/lib/firefox/libplc4.so", mode=ct.RTLD_GLOBAL)
self.libnss3 = ct.CDLL("/usr/lib/firefox/libplds4.so", mode=ct.RTLD_GLOBAL)
self.libnss4 = ct.CDLL("/usr/lib/firefox/libnssutil3.so", mode=ct.RTLD_GLOBAL)
self.libnss = ct.CDLL("/usr/lib/firefox/libnss3.so")

Obviously not very universal...

[jrw]

    def __init__(self, non_fatal_decryption=False):
        # Locate libnss and try loading it
# jrw   self.libnss = load_libnss()
        LOG.debug("JRW 1")
        self.libnss1 = ct.CDLL("/usr/lib/firefox/libnspr4.so", mode=ct.RTLD_GLOBAL)
        self.libnss2 = ct.CDLL("/usr/lib/firefox/libplc4.so", mode=ct.RTLD_GLOBAL)
        self.libnss3 = ct.CDLL("/usr/lib/firefox/libplds4.so", mode=ct.RTLD_GLOBAL)
        self.libnss4 = ct.CDLL("/usr/lib/firefox/libnssutil3.so", mode=ct.RTLD_GLOBAL)
        self.libnss = ct.CDLL("/usr/lib/firefox/libnss3.so")
        LOG.debug("JRW 2")

This is executing, but then later I get

2025-11-11 20:16:03,731 - DEBUG - JRW 1
2025-11-11 20:16:03,731 - DEBUG - JRW 2
2025-11-11 20:16:03,731 - DEBUG - Reading profiles from /home/.../.mozilla/firefox/profiles.ini
2025-11-11 20:16:03,732 - DEBUG - Read profiles ['Profile0', 'Install4F96D1932A9F858E', 'Install6230AD9FB497EC11', 'General']
2025-11-11 20:16:03,732 - DEBUG - Initializing NSS with profile 'sql:/home/.../.mozilla/firefox/....default-release'
2025-11-11 20:16:03,732 - DEBUG - Initializing NSS returned -1
2025-11-11 20:16:03,732 - ERROR - Couldn't initialize NSS, maybe '/home/.../.mozilla/firefox/....default-release' is not a valid profile?
2025-11-11 20:16:03,732 - DEBUG - PR_LOAD_LIBRARY_ERROR: Failure to load dynamic library

[pepa65]

I get:

2025-11-12 10:55:36,425 - DEBUG - Reading profiles from /home/pp/.mozilla/firefox/profiles.ini
2025-11-12 10:55:36,426 - DEBUG - Read profiles ['Install4F96D1932A9F858E', 'Profile0', 'General']
2025-11-12 10:55:36,426 - DEBUG - Initializing NSS with profile 'sql:/home/pp/.mozilla/firefox/d8nzz3ks.default-1610096794353'
2025-11-12 10:55:36,427 - DEBUG - Initializing NSS returned 0
2025-11-12 10:55:36,427 - DEBUG - Retrieving internal key slot
2025-11-12 10:55:36,427 - DEBUG - Internal key slot <__main__.LP_PK11SlotInfo object at 0x79482414f9d0>

And then it asks for the password, and it works.

[jrw]

When I run the same code with LD_LIBRARY_PATH set, it works. I don't know what's going on there, because the 5 libraries are apparently loaded successfully in both cases from your changes that I copied.

[pepa65]

What is your output of: LD_LIBRARY_PATH=/usr/lib/firefox ldd /usr/lib/firefox/libnss3.so

[jrw]

$ LD_LIBRARY_PATH=/usr/lib/firefox ldd /usr/lib/firefox/libnss3.so linux-vdso.so.1 (0x00007fff1f87c000) libnspr4.so => /usr/lib/firefox/libnspr4.so (0x00007ff19b3e3000) libplc4.so => /usr/lib/firefox/libplc4.so (0x00007ff19b3dc000) libplds4.so => /usr/lib/firefox/libplds4.so (0x00007ff19b3d6000) libnssutil3.so => /usr/lib/firefox/libnssutil3.so (0x00007ff19b3a3000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff19b383000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff19b37c000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff19b153000) /lib64/ld-linux-x86-64.so.2 (0x00007ff19b4e9000)

[pepa65]

That is very similar to mine... No idea why yours wouldn't work. What Firefox are you using for this? I have 144.0.2.

[jrw]

FF 145.0 on Linux Mint

[pepa65]

Okay, just got 145.0 myself. But the decryption still works here with that version...

[jrw]

Synaptic is showing 145.0+linuxmint1+virginia as the installed version It was upgraded 11/11 (yesterday) I think it's coming directly from the mozilla repos due to /etc/apt/sources.list.d/mozilla-apt-repo.list which I believe was brought in as part of the Mozilla VPN which I have.

[pepa65]

I have 145.0+linuxmint1+zara from http://packages.linuxmint.com zara/upstream amd64 which is the default.

EDIT: For it to work, I have found that I just need to replace the line self.libnss = load_libnss() by:

self.libnss = ct.CDLL("/usr/lib/firefox/libnssutil3.so")
self.libnss = ct.CDLL("/usr/lib/firefox/libnss3.so")