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

Projects
None yet
4 participants
@atomic111
Member

atomic111 commented May 6, 2014

Also i adjusted the kitchen test and tested it

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

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

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

This comment has been minimized.

Show comment
Hide comment
@chris-rock

chris-rock May 7, 2014

Member

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

Member

chris-rock commented May 7, 2014

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

This comment has been minimized.

Show comment
Hide comment
@bkw

bkw May 7, 2014

Contributor

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?

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 chris-rock referenced this pull request May 7, 2014

Closed

enfore security updates #7

@chris-rock

This comment has been minimized.

Show comment
Hide comment
@chris-rock

chris-rock May 7, 2014

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

Member

chris-rock commented May 7, 2014

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

This comment has been minimized.

Show comment
Hide comment
@bkw

bkw May 7, 2014

Contributor

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'...

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

This comment has been minimized.

Show comment
Hide comment
@chris-rock

chris-rock May 7, 2014

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?

Member

chris-rock commented May 7, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@chris-rock
Member

chris-rock commented May 7, 2014

loop in @arlimus

@bkw

This comment has been minimized.

Show comment
Hide comment
@bkw

bkw May 7, 2014

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@chris-rock

chris-rock May 7, 2014

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

Member

chris-rock commented May 7, 2014

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

This comment has been minimized.

Show comment
Hide comment
@arlimus

arlimus May 8, 2014

Member

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.

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