pfSense

One should also consider removing support for AES-128. Based on Grover's Algorithm, AES's strength is cut in half. While AES-256 (and other 256bit symmetric crypto) is fine, 128bit symmetric crypto (like AES-128) is not.

Current:
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

Recommended:
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr

There isn't any remotely modern SSH client that doesn't support AES-256. Plus, with CPU acceleration for AES (like AES-NI and QAT) the performance difference is academic. And for the few systems without CPU acceleration, SSH is not a major management route to most pfSense instances anyway, so it's extremely unlikely that any user will notice.

Jim Pingle wrote in #note-3:

Needs a little more time so we can fix up the SSH server ciphers as well and make sure everything is current/optimal.

So you guys are kind of in an odd spot. The current "industry standard" key exchange algorithm you really should be using (hybrid ML-KEM + x25519) is not available in FreeBSD 15. For that you’ll need OpenSSL 3.5+ and OpenSSH 9.9+.

Not sure when FreeBSD will update to the newer versions. Debian, Fedora, RHEL, Arch, and others have it. In the meantime, you can do a few things to be a little more quantum safe:

-Use the hybrid NTRU KEX in SSH. (It’s not the one NIST selected, but it’s still better than just relying on x25519 alone).
-Use larger ECC curves, like p384 (for TLS).
-Use a 265-bit symmetric ciphers in AEAD mode (like AES256-GCM).
-Disable TLS 1.2, only allow 1.3.

That was the point of this request. Try to get pfSense a little safer until FreeBSD catches up with the other OSes. I can also appreciate not being interested in making changes until FreeBSD implements broad support for hybrid ML-KEM.

The upcoming Plus 25.11 release has OpenSSL 3.5.3 and OpenSSH 10.0p2: https://docs.netgate.com/pfsense/en/latest/releases/25-11.html

Jim Pingle wrote in #note-5:

The upcoming Plus 25.11 release has OpenSSL 3.5.3 and OpenSSH 10.0p2: https://docs.netgate.com/pfsense/en/latest/releases/25-11.html

That makes this easy then. Once on OpenSSH 10+, consider setting the KEX list to:

KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com,ecdh-sha2-nistp384,curve25519-sha256,curve25519-sha256@libssh.org

I put the NTRU and MLKEM based hybrids first. NTRU is there as a steppingstone, since many SSH clients support it, but only the latest clients support MLKEM. MLKEM is the de facto standard, so it gets the top spot.

I added the p384 curve, which is stronger (yet equally well supported) as the 25519 curve.

For the KEX that have two names (see ssh -Q kex) I included both. Some SSH clients care about the specific variant of a KEX, some don’t care. This maximizes compatibility, without any security impact.

I took out diffie-hellman-group-exchange-sha256, since it’s ancient and slow. In the TLS world, DHE has been effectively abandoned, replaced with 25519, p256, and p384 (and more recently, the MLKEM hybrid). RFC 9142 says it only has 112-bits of security; well below modern accepted minimums.

Another thing I just spotted, the non-ETM hashes should be removed (Encrypt Then Mac). The TLS world long removed the non-ETM hashes due to known security issues, replacing them with ETM, and more recently AEAD hashes. A recommendation would be:

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

One quick revision to the block cipher recommendation. Since the vast majority of pfSense hardware can support AES offloading, that should be ahead of ChaCha20. With CTR mode at the end, since it’s slower and weaker. Any thing less that 256 completely removed.

Ciphers aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr