Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 1 commit into from
May 7, 2014

Conversation

atomic111
Copy link
Member

Also i adjusted the kitchen test and tested it

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

…txt/gcmrekey.adv

Signed-off-by: Patrick Meier <patrick.meier111@googlemail.com>
@chris-rock
Copy link
Member

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

chris-rock added a commit that referenced this pull request May 7, 2014
@chris-rock chris-rock merged commit 076434e into dev-sec:master May 7, 2014
@bkw
Copy link
Contributor

bkw commented May 7, 2014

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
Copy link
Member

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
Copy link
Contributor

bkw commented May 7, 2014

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
Copy link
Member

@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
Copy link
Member

loop in @arlimus

@bkw
Copy link
Contributor

bkw commented May 7, 2014

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
Copy link
Member

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
Copy link
Member

arlimus commented May 8, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants