remove aes-gcm algos from Ciphers, because of http://www.openssh.com/txt/gcmrekey.adv

[atomic111]

Also i adjusted the kitchen test and tested it

Signed-off-by: Patrick Meier patrick.meier111@googlemail.com

[chris-rock]

great @atomic111 . just tested it and it works as expected.

[bkw]

Hasn't this been fixed by all distributions? If we continue like that we would have to forbid any server that ever had an exploit, because who knows...

I'd rather enforce a security update repository to be configured and the version of openssh-server to be current.

Comments?

[chris-rock]

Currently we set the ciphers for ssh via templates and enfore a specific set. From my perspective we should not expect a specific operating system to have a secure default configuration. The idea to enfore security updates is great, but from my perspective this should be enforced in https://github.com/TelekomLabs/chef-os-hardening

[bkw]

Hmm... That set of ciphers will become smaller and smaller until there are no ciphers left that never ever had a buggy implementation. And then what?
And, I don't think we can rely exclusively on configuration, sometimes you either have that patch or you don't, and there is no parameter to disable the exploitable feature. Take CVE-2007-3102. Ancient, yes. But if you don't enforce a minimum version, there is no way to find out wether you are vulnerable or not. Even the OVAL check uses version numbers.
Just sayin'...

[chris-rock]

@bkw good point. which leads us to a more general problem: enforce a minimum versions + patch management. Currently we update to the latest patch level with os-hardening. I am not sure if we should do an extra enforcing of a minium version for each service?

[chris-rock]

loop in @arlimus

[bkw]

I didn't want to derail this, let's just keep it in mind. We might add a blacklist of vulnerable versions later on, or fuse this with some cve database.

[chris-rock]

I've put the questsions into our backlog, because they are not restricted to ssh. We need an answer for all hardening projects. See https://trello.com/b/gL9v8N1q/dt-hardening

[arlimus]

Good point regarding ciphers. Distros will usually continue supporting certain algos even though the crypto community either rejects or recommends against them. This is true for ssh and many others (nginx, apache, ...)

I think the review of these algos is part of this project to deliver a 'good' subset. Even if there are some issues remaining, a best selection is what we should deliver. The user should have the option to slightly open it up for compatibility if necessary with another ok subset, as in this project.