"weak ciphers" confusing entry in Services/SSH configuration

Revan

Explorer
Joined
Mar 22, 2017
Messages
81
In TrueNAS-12.0-U1.1 under Services/SSH -> Advanced options there is a configuration option called "Weak Ciphers" with predefined entries with the values "None, AES-128-CBC."

But what isn't said is the meaning of that entry.
Does it mean, that all those ciphers, that are listed in Weak Ciphers are not used and thus deactivated or does it mean, these ciphers are activated by default and used because they are listed?

If the options is there to deactivate these ciphers, i would recommend to rename it to "deactived ciphers" and then list them.
Or better, don't list them, and deactive them by default and if someone wants to activate it, the option should be called "additional activated ciphers to use".

At the moment it is very confusing and the meaning if activated or deactivated is unclear.

The help button is also not of much help, because it only says "Allow more ciphers for sshd(8)..."
and the article from "TrueNAS Documentation Hub/Initial Setup/Networking/SSH Connections" seems to be outdated because there is no option called "weak ciphers", instead there the text talks about something like "Add NoneEnabled no to disable the insecure none cipher.".
 

Samuel Tai

Never underestimate your own stupidity
Moderator
Joined
Apr 24, 2020
Messages
5,399
Click on the tool-tip question mark in the circle for the answer:

1612732981339.png


Basically, None allows fallback all the way to unencrypted sessions. AES128-CBC allows fallback only to AES128-CBC as the weakest cipher.
 

Revan

Explorer
Joined
Mar 22, 2017
Messages
81
Click on the tool-tip question mark in the circle for the answer:

View attachment 44956

Basically, None allows fallback all the way to unencrypted sessions. AES128-CBC allows fallback only to AES128-CBC as the weakest cipher.

Please read more carefully, i wrote:
The help button is also not of much help, because it only says "Allow more ciphers for sshd(8)..."

and
If the options is there to deactivate these ciphers, i would recommend to rename it to "deactived ciphers" and then list them.
Or better, don't list them, and deactive them by default and if someone wants to activate it, the option should be called "additional activated ciphers to use".

GUI Usability is made by making options meaningful and not confusing.
 

Revan

Explorer
Joined
Mar 22, 2017
Messages
81
Because a picture can explain more than a thousands words, here are two examples:

Bad confusing misleading GUI design (the current situation):
bad_gui_design.png


Very good meaningful clear GUI design (how it should be):
very_good_gui_design.png
 

Samuel Tai

Never underestimate your own stupidity
Moderator
Joined
Apr 24, 2020
Messages
5,399
Although your GUI mockups are clearer, I don't believe the ciphers are actually deactivated.
 

Revan

Explorer
Joined
Mar 22, 2017
Messages
81
Although your GUI mockups are clearer, I don't believe the ciphers are actually deactivated.
Well, and that's the reason why the current GUI is unclear and confusing.

It does only allow to guess, what the option "weak ciphers" does.
And that's the main problem and the reason for this thread.

We all know, that "none" and "AES128-CBC" are weak ciphers. But this doesn't help, if the GUI isn't meaningful.
 
Joined
Oct 22, 2019
Messages
3,641
We all know, that "none" and "AES128-CBC" are weak ciphers. But this doesn't help, if the GUI isn't meaningful.
If one or both of those options are checked, then you are allowing the SSH service to "fallback" to either AES-128-CBC or None.

In my opinion, there's no reason to check any of those two options. Leaving them both unchecked is more secure, and with modern devices, any overhead on performance losses are practically unnoticeable.

By the looks of your first screenshot, you have both of those options enabled.

Well, and that's the reason why the current GUI is unclear and confusing.
It might have been more clear if it was worded like this, with a tooltip explaining why it's discouraged:
Allow SSH to fallback on the following weak ciphers
 

Samuel Tai

Never underestimate your own stupidity
Moderator
Joined
Apr 24, 2020
Messages
5,399
@winnielinnie, the default in the SSH service is None. The most secure option is to set AES128-CBC.
 
Joined
Oct 22, 2019
Messages
3,641
the default in the SSH service is None. The most secure option is to set AES128-CBC.
I never touched that option, as it has always remained "unfilled". Where does it say TrueNAS ships with the default as "None" out of the box?
 

Samuel Tai

Never underestimate your own stupidity
Moderator
Joined
Apr 24, 2020
Messages
5,399
Actually, you are correct. If you run midclt call ssh.config | jq, and look for weak_ciphers, the default value is NULL.
 

Revan

Explorer
Joined
Mar 22, 2017
Messages
81
By the looks of your first screenshot, you have both of those options enabled.
The first screenshot shows the setting how it is on a fresh install.
 
Joined
Oct 22, 2019
Messages
3,641
Perhaps because my system was an upgrade from 11.3? I never did a fresh install of 12.X. I don’t recall ever touching that option, but I’m going to check out a VM to see what it defaults to. Either way, mine are unfilled (i.e, neither “fallback weak cipher” allowed) and I’ve had no performance issues with SSH, rsync (over SSH), or scp.
 

Samuel Tai

Never underestimate your own stupidity
Moderator
Joined
Apr 24, 2020
Messages
5,399
Mine was also an upgrade from 11.3-U5, and weak_ciphers was originally NULL.
 
Joined
Oct 22, 2019
Messages
3,641
Mine was also an upgrade from 11.3-U5, and weak_ciphers was originally NULL.
Just confirmed on two separate fresh installations.

FreeNAS 11.3-U5 defaults to null.

TrueNAS 12.0-U1.1 defaults to allowing "None" and "AES128-CBC"

It was possibly changed for the sake of speed and performance, since within a local network, an unencrypted stream between two devices is not as big of a deal?

But with modern CPUs, and the possibility of later deciding to do remote transfers, it makes sense for me to disable both fallback weak ciphers if you don't mind a small dip in performance (which as a home user is probably not even noticeable.)

EDIT: As far as I'm aware, unless the remote device (whether acting as a client or server) is running older hardware / older SSH, the cipher used between them will not fallback to a weak cipher (or "none"), regardless.
 
Last edited:
Joined
Oct 22, 2019
Messages
3,641
To unveil some of the mystery, here is what enabling each of those settings does.

Enabling "None" inserts the following line into sshd_config:
NoneEnabled yes

Enabling "AES128-CBC" inserts the following line into sshd_config:
Ciphers +aes128-cbc

Disabling (unchecking) those two options essentially removes the above two lines from the config file.

Don't edit sshd_config directly! This is just to illustrate what checking those two options does under-the-hood.

I'm going to leave both of mine unchecked, as I've had no issues and would rather not implicitly allow "no encryption" over SSH.
 

Revan

Explorer
Joined
Mar 22, 2017
Messages
81
That's the configuration after a fresh install, when i press the drop down button of that "Weak Ciphers" entry:

default_config.png


"None" and "AES128-CBC" have both a checkmark set.

Because of the bad GUI it is still not clear, what the results of unchecking or checking these checkmarks are?
Are these Ciphers disabled by setting the checkmark, because that menu option is called "weak chipher" or are they enabled when setting the checkmark?

To know that, a user must look into the /etc/ssh/sshd_config file

EDIT:
Correction, the file is in /etc/local/ssh/
 
Last edited:

Revan

Explorer
Joined
Mar 22, 2017
Messages
81
If you want have "None" and "AES128-CBC deactived it must look like this in the GUI:

deactivated_1.png

and if you press the drop-down menu button it must look like this:

deactivated_2.png


I can only repeat, the way this ssh GUI is designed is really bad and should be changed to make it clearer.
If you are unsure, you can test with the following two commands if one of the weak ciphers are enabled:

Code:
grep -C 5 -i NoneEnabled /etc/local/ssh/sshd_config
grep -C 5 -i AES128 /etc/local/ssh/sshd_config

If the console output is empty, everything is correct. If something is shown, the weak Ciphers are activated.

I also do miss an Option to show the ECDSA key fingerprint in the GUI.
If you connect via ssh to the server, you will asked to verify the ECDSA key fingerprint with the fingerprint that is shown in the console.
To verify it, you need to get the fingerprint via a save way. Like the webinterface, but the webinterface is of no help here.

Thus to get the ECDSA key fingerprint you need to switch to the shell in the webinterface and read the Fingerprint via the commandline with the following command:


Code:
ssh-keygen -lf /etc/local/ssh/ssh_host_ecdsa_key.pub

This will print the ECDSA key fingerprint into the console.
 
Joined
Nov 18, 2015
Messages
4
@Revan Thank you for pointing this out. I completely agree with your sentiment.

The UI should make it abundantly clear that algorithms with checkmarks are enabled. The heading should say something like "Enabled weak ciphers", and the help box should be even more clear.
 

StanTheMa

Dabbler
Joined
Jun 30, 2020
Messages
13
@Revan on your last point I agree just spent an hourlooking for host ECDSA fingerprint in GUI and then not finding it cos I forgot the /etc/local/...
I was trying to verify for a ssh connect from a vmware hosted kali linux. Thanks for your notes.
 

smrqdt

Cadet
Joined
Apr 19, 2021
Messages
1
Oh no, this is a horrible default setting behind some horrible UI in a horrible hidden place. Especially because it is set as default I wasn’t sure whether this setting meant “enable” or “disable” weak ciphers and had to google.

This setting really seems to be default on fresh TrueNAS 12 install (checked with U4 and found in instances set up as U3).

There is an Issue that has been closed as “Not to be Fixed“ because “That was required so upgrades would not break setups.“, but that does not explain why it’s default for fresh installs.
 
Top