The current list of FIPS algorithms in openssh is wrong and contains some non-approved ciphers but it is missing some approved ones. The list should be for ciphers: 3des-cbc aes128-cbc aes192-cbc aes256-cbc rijndael-cbc.se aes128-ctr aes192-ctr aes256-ctr Note that means removing aes-gcm as that is not approved for use with anything else than IPSec and TLS in FIPS. for macs: I'd remove the sha1-96 macs at least. I'd keep the sha1 macs as that might be needed for interoperability however it's status is questionable. for kex: I'd remove key exchanges that use sha1. We'll see if the interoperability with so limited key exchange methods will be reasonable.
Thanks for the report. I will update the list with next update. * I will remove the *gcm ciphers from FIPS mode available ciphers. It is not in default proposal, but it still can be selected: # ssh -oCiphers=aes256-gcm -G test | grep gcm FIPS mode initialized ciphers aes256-gcm * The mac sha1-96 is not in default proposal (even for non-FIPS) and it does not work in FIPS: $ ssh -oMACs=hmac-sha1-96 -G test | grep hmac-sha1-96 command-line line 0: Bad SSH2 Mac spec 'hmac-sha1-96'. * About Kex, I see in default proposal diffie-hellman-group-exchange-sha1, diffie-hellman-group14-sha1 where, both of them are still in FIPS default proposal. We can remove them from FIPS list. The diffie-hellman-group1-sha1 is already disabled.
(In reply to Jakub Jelen from comment #1) > * About Kex, I see in default proposal > > diffie-hellman-group-exchange-sha1, > diffie-hellman-group14-sha1 > > where, both of them are still in FIPS default proposal. We can remove them > from FIPS list. The diffie-hellman-group1-sha1 is already disabled. OK, please remove them from the FIPS list.
Interesting enough, ecdh-sha2-nistp*, key exchanges are failing in FIPS mode (server side), because of SECCOMP (with PrivilegeSeparation sandbox). Investigating the reasons ... I see SIGSYS under fips_check_ec(). Any idea what is there different in FIPS related to syscalls? ssh_sandbox_violation: unexpected system call (arch:0xc000003e,syscall:41 @ 0x7f2dbf827c07) [preauth] [root@f23 ~]# ausyscall 41 socket Tomas, do you have some idea why does openssl need socket syscall in FIPS mode (in preauth)? It does not happen without FIPS.
You mean it does socket() syscall? That's weird. I do not see anything like that in the code. Can you strace it or find the backtrace via gdb?
Created attachment 1146003 [details] backtrace from SIGSYS in FIPS mode Added as an attachment. It is quite long. Let me know if I should get something more. And I hope it is not my machine broken.
OK, that is legitimate call although it is not needed and it can fail. I do not know whether it is possible to make some syscalls fail without the SIGSYS with the seccomp.
Yes, we can tell seccomp to fail with various return codes if the syscall is not allowed. EACCESS is probably most appropriate. Thank you for the comments. I will test if there will not show up something else and cover it with the next update.
Tested and works fine. I pushed the changes to dist-git. Builds will come later. It does not look critical since nobody noticed for a year since we enabled seccomp.
openssh-7.2p2-4.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-965bd6926e
openssh-7.2p2-4.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-965bd6926e
openssh-7.2p2-4.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.