Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: Hugo Trippaers <HTrippaers@schubergphilis.com>
To: "<cloudstack-dev@incubator.apache.org>"
	<cloudstack-dev@incubator.apache.org>
CC: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
Subject: Re: proper SSL/ssh management
Thread-Topic: proper SSL/ssh management
Thread-Index: AQHNcbEPgWpnmBSKfU2SpKIchiP/iZdIq5JT
Date: Fri, 3 Aug 2012 22:29:42 +0000
Message-ID: <CA34F0EB-B79C-4E11-B8BE-926388CE1738@schubergphilis.com>
References: <3894C846-6687-4381-B456-043FEADD5CBC@stratosec.co>
In-Reply-To: <3894C846-6687-4381-B456-043FEADD5CBC@stratosec.co>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hey John,

Completely agree!

I think it's pretty easy to make a central config flag for that. If it is t=
here I will use that flag to check before loading the trust managers.

Cheers,

Hugo=20

P.S. what about a hardening guide for CS?

Sent from my iPhone

On 3 aug. 2012, at 21:49, "John Kinsella" <jlk@stratosec.co> wrote:

> Arve's made a comment in the "Official ASF process for re-writing code" t=
hread about accepting SSL certs that I wanted to comment on, without hijack=
ing that thread:
>=20
> CloudStack (and most (maybe all) Cloud management platforms I've seen) bl=
indly accept any ssh host keys or SSL certificates they encounter. As a sec=
urity guy, to me this is Bad - we're throwing out a key ability to recogniz=
e impostors.
>=20
> What I'd like to see is probably a "don't blindly trust keys" configurati=
on option that's disabled by default. That way, those who like the status q=
uo can continue right along.
>=20
> In my mind, I envision the following functionality to be enabled when the=
 configuration flag is enabled:
> * ssh connections between mgmt server/hosts and between hosts/SSVMs would=
 NOT blindly accept ssh keys, but would log an error that's clearly logged =
specifying that either a host key mismatch or an unrecognized key was encou=
ntered.  This then becomes an admin's problem to fix.
> * SSL based connections would similarly not blindly trust a self-signed o=
r mismatched SSL certificate, but attempt the verification and only proceed=
 if the cert was validated. Otherwise, detailed error is logged specifying =
the service, host, and key. This then becomes an admin's problem to fix.
>=20
> Possibly a simple utility script similar to the SSVM test script could be=
 written that would check to make sure that various ssh/ssl connections are=
 working properly, and if not would clearly point them out.
>=20
> Thoughts? I'm not expecting to fix this for CS4, but if we can come to a =
general agreement we can throw it on the roadmap.
>=20
> John
>=20
> Stratosec - Secure Infrastructure as a Service
> o: 415.315.9385
> @johnlkinsella
>=20