Project

General

Profile

Actions

Correction #13494

closed

Documentation on decryption of encrypted config.xml files is not correct

Added by Dennis Adler over 1 year ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Backup / Restore
Target version:
-
Start date:
Due date:
% Done:

100%

Estimated time:

Description

The information listed in the pfSense online manual at https://docs.netgate.com/pfsense/en/latest/backup/restore.html, which was changed in response to a previous bug (https://redmine.pfsense.org/issues/11162 -- hence the regression tag) does not allow me to decrypt newer backup files. The online manual references v2.5.0 (CE?); I tested this against 22.05 but suspect it impacts every version that uses the more secure password hashing algorithm for encrypting backups.

For all of the details, please see the TAC ticket https://portal.netgate.com/tickets/details/1105865744?back=tickets. I'm just listing the doc fixes in this bug.

First, it is not necessary to use grep to strip the BEGIN or END lines, nor is it necessary to base64 decode the file first. OpenSSL, at least as of v1.1.1, is quite happy to deal with these files as-is if you simply add "-a" to the decryption switch set. If you really want to lean things down, according to other online sources I read, you can do away with "-salt" as that is automatically added (though I DID NOT verify that)

The pre-2.5.0 decryption can happen with a single command. Using Windows CMD file format, the line would be:

openssl enc -d -a -aes-256-cbc -md md5 -in %1 -out %2

Where %1 is the input file (encrypted, base64 format) and %2 is the desired output file.

For 2.5.0 and later, this changes slightly:

openssl enc -d -aes-256-cbc -salt -md sha256 -pbkdf2 -salt -iter 500000 -a -in %1 -out %2

Same arguments as the pre-2.5.0 version. Again, you may be able to remove the -salt argument; further according to OpenSSL documents, -iter forces -pbkdf2. It does not hurt to leave these there though.

I have tested the pre-2.5.0 command on some older, pre 2.5 SG-3100 files and it works as expected. I had to search the GitHub sources (specifically, https://github.com/pfsense/pfsense/blob/master/src/etc/inc/crypt.inc) to learn the iteration count. Without the same iteration count, the password string supplied will not decrypt the file, whether or not the password supplied is the same one that works in the GUI.

This has been an on-going discussion on Netgate forums, e.g. see https://forum.netgate.com/topic/139561/pfsense-xml-config-file-can-we-decrypt-it-manually?_=1663227540973. Both the support tech on my TAC ticket and RColeman (a Netgate admin on the form) asked me to submit this via Redmine... so here it is.

If I may be so bold: you might want to add commends to crypt.inc noting these doc pages need to be changed anytime the algorithm or password handling (like iterations) change. I am curious, if you would care to share, how pfSense decides which method to use; do you simply try decrypting with the old pw style and then the new, to see what happens?

Please note I did not test this on my SG-5100 (i.e. did not run this using Diagnostics / Command Prompt or with the serial console and shell. I would hope that OpenSSL behaves the same on Windows as FreeBSD, so you may want to test this decryption in your lab on a pfSense install to be sure it has the same behavior.

Draco

Actions

Also available in: Atom PDF