<div dir="ltr">Hi y'all!<div><br></div><div>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?</div>
<div><br></div><div>I'm mostly working off this document in producing this feedback:  <a href="https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL">https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL</a></div><div><br></div>
<div><b>Regarding storing private keys:</b></div><div><br></div><div>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?)</div>
<div><br></div><div>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. :/</div><div><br></div><div><b>Future Design Considerations:</b>  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.</div>
<div><br></div><div><b>SSL Policies Managing:</b></div><div>What are the fields under the 'Pass info' section? "Bits" I get, but shouldn't this be informational?</div><div><br></div><div>Also: <span style="color:rgb(51,51,51);font-family:'Arial Unicode MS',Arial,sans-serif;font-size:14px;line-height:20px">“Front-End-Https:"  Er... everywhere else I've seen, that field is "X-Forwarded-Proto: https"</span></div>
<div><span style="color:rgb(51,51,51);font-family:'Arial Unicode MS',Arial,sans-serif;font-size:14px;line-height:20px"><br></span></div><div><span style="color:rgb(51,51,51);font-family:'Arial Unicode MS',Arial,sans-serif;font-size:14px;line-height:20px">Any thoughts on adding support for HSTS here as well? ( </span><font color="#333333" face="Arial Unicode MS, Arial, sans-serif"><span style="font-size:14.399999618530273px;line-height:20px"><a href="http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security">http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security</a> )</span></font></div>
<div><br></div><div><b>SSL Certificates Managing:</b></div><div><br></div><div>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.</div>
<div><br></div><div>And again, I don't see how we can do automated restarts of services without having a persistent private SSL key.</div><div><br></div><div>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.)</div>
<div><br></div><div>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.</div>
<div><br></div><div><b>On all views which present a list of SSL certificates:</b></div><div>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.</div>
<div><br></div><div><b>SSL Trusted Certificates Managing:</b></div><div>Are these for authenticating web clients connecting to the HTTPS front-end?</div><div><br></div><div><b>Front-end versus back-end protocols:</b></div>
<div>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!</div>
<div><br></div><div>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.</div><div><br></div><div><b>Default cert when using SNI:</b></div>
<div>So...  while I can see that SNI is implicitly supported by:</div><div><ul style="padding:0px;margin:0.3em 0px 0px 1.6em;color:rgb(51,51,51);font-family:'Arial Unicode MS',Arial,sans-serif;font-size:14px;line-height:20px">
<li>vip_ssl_certificate_assoc (new, multiple certificates per vip. certificate may be associated with multiple vips)</li></ul></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br clear="all"><div>Thanks,</div><div>
Stephen</div><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807

</div></div>