Open Stack

Hi y'all!

Good news! This is the last of the mile-long posts I said I would write
after the initial post last week proposing the major model change. Yay for
small miracles, right?

I'm mostly working off this document in producing this feedback:
https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL

*Regarding storing private keys:*

Please let me know if y'all want suggestions here. In our implementation we
encrypt sensitive data like this using a data encipherment passphrase (ie.
long string of gobbledygook) stored on the cloud OS application servers
before storing the encrypted SSL keys in the database. (So, encrypted SSL
key, and the decipherment passphrase are not collocated data at rest.) In
order for this to be effective in an OpenStack environment, the database
needs to not live on the same hardware as the API server. In any case, this
is a pretty solvable problem (and maybe we can delegate it to barbican?)

Also, it should be pointed out that load balancer vendors should hopefully
take pains to ensure private SSL keys are encrypted at rest when stored on
their appliances. :/

*Future Design Considerations:*  I do not think it's going to be possible
to *not* remember the private key. Specifically, certain API requests will
entail updating various aspects of the load balancer configuration that
will also require restarting processes, etc. in an automated way. It's not
possible to restart haproxy or stunnel with an encrypted private key
without providing the decipherment passphrase, which may not be available
with all API calls.

*SSL Policies Managing:*
What are the fields under the 'Pass info' section? "Bits" I get, but
shouldn't this be informational?

Also: “Front-End-Https:"  Er... everywhere else I've seen, that field is
"X-Forwarded-Proto: https"

Any thoughts on adding support for HSTS here as well? (
http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security )

*SSL Certificates Managing:*

What are your thoughts on stripping the passphrase the user enters when
adding a certificate? Don't misunderstand: I think private SSL keys should
be stored encrypted, but I'd much rather we rely on a machine-generate 80+
character-long passphrase for this than the "abc123" passphrase some users
will definitely have entered when they generated their certificate requests.

And again, I don't see how we can do automated restarts of services without
having a persistent private SSL key.

Also note that when adding or updating a certificate, we should immediately
check the modulus of the public certificate against the modulus of the
private SSL key. If they do not match, we should return an error.
(Mismatching cert and key are a very common problem we encounter.)

And! In the edit screen: We should allow the user to enter a new
certificate and CA chain. It's common for certificate authorities to renew
SSL certificates without re-issuing the private SSL key.

*On all views which present a list of SSL certificates:*
Please also list the common name (CN) of the certificate, all X509v3
Subject Alternative Names, number of bits in the private SSL key, and the
expiration date of the certificate.  (It's also worthwhile highlighting in
red any certificates which are expired.)  It might not hurt to show the
key's fingerprint or modulus as well.

*SSL Trusted Certificates Managing:*
Are these for authenticating web clients connecting to the HTTPS front-end?

*Front-end versus back-end protocols:*
It's actually really common for a HTTPS-enabled front-end to speak HTTP to
the back-end.  The assumption here is that the back-end network is
"trusted" and therefore we don't need to bother with the (considerable)
extra CPU overhead of encrypting the back-end traffic. To be honest, if
you're going to speak HTTPS on the front-end and the back-end, then the
only possible reason for even terminating SSL on the load balancer is to
insert the X-Fowarded-For header. In this scenario, you lose almost all the
benefit of doing SSL offloading at all!

If we make a policy decision right here not to allow front-end and back-end
protocol to mismatch, this will break a lot of topologies.

*Default cert when using SNI:*
So...  while I can see that SNI is implicitly supported by:

   - vip_ssl_certificate_assoc (new, multiple certificates per vip.
   certificate may be associated with multiple vips)


In any given SNI configuration, you still need to specify a 'default' cert
to use if the client uses a protocol that doesn't support SNI, or if none
of the various hostnames from the configured certificates match the
hostname that the client has requested.  To solve this, I would recommend
adding a 'default' boolean field to the vip_ssl_certificate_assoc object,
have this be set to "true" for the first certificate associated with the
VIP, and write a validation (in the agent code) that exactly one
certificate associated with a given VIP is marked as default whenever the
VIP<->ssl_certificate associations are created or modified.

In the screen associating certificates with a given VIP, we need to provide
a field (checkbox?) for the user to specify which one of them is the
default.

Thanks,
Stephen

-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140219/7cd827fc/attachment.html>