Open Stack

Hi Jeff,

First off, thank you for taking the time to feed back your thoughts on the
SSL/TLS section of the security guide, it's great when we get this sort of
response.

I've addressed a number of your points here:
https://review.openstack.org/44563 but there were a few that were really
out of scope, while I'm happy to have a conversation about how fit for
purpose the whole CPS/RA/CA arrangement is, there's no other options on
the table for securing OpenStack communications. The choice our users have
is to enable SSL or not, so we need to provide the best guidance on where
and how to configure it.

Writing this, I realise that I've not provided guidance on PFS in the
above review, I'll have to address that in an amendment.

I found your email below very interesting, if you can bring the same depth
of expertise to other parts of the guide I'm sure we'll benefit greatly!

Cheers
-Rob

On 30/08/2013 19:39, "Jeffrey Walton" <noloader at gmail.com> wrote:

>Hi All,
>
>I'm reading through the Security Guide. Its very good work. Great job.
>
>Around page 73 a discussion of PKI and SSL/TLS begins. The following
>comments may be helpful.
>
>Most of this is well known, but its not in the marketing literature.
>Its the darker side to PKI and SSL/TLS, and its covered in a number of
>security engineering books, like Peter Gutmann's Engineering Security
>(www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf?) or Ross Anderson's
>Security Engineering (http://www.cl.cam.ac.uk/~rja14/book.html).
>
>I think its important to realize the gaps in these systems because
>once the data is lost it cannot be recovered. And not everyone has
>shareholders to pass losses onto.
>
>****
>
>"The core components of PKI are..." - the list is missing the Relying
>Party. This is important because of the legal behind most PKI
>deployments using the Internet profile (RFC 5280 and friends). There's
>a big disconnect between what the Relying Party is expecting, and what
>the CA is providing. In fact, the a CA's Certification Practice
>Statement (CPS) will likely disclaim nearly all warranties and shed
>all liabilities.
>
>The humor was not lost on me: we - the relying parties - use PKI and
>CAs to solve the key distribution problem. But the infrastructure does
>not deliver what we want, need, or expect in many cases.
>
>*****
>
>"Certification Authority (CA) - defines certificate policies,
>management, and issuance of certificates" - that's getting into
>details usually covered by the CPS. The CA is just a vending machine
>that accepts money and issues certificates.
>
>The details of policies, issuance, management and revocation are
>covered by the CPS. The CPS is legally binding; hence the reason the
>CA disclaims nearly all warranties and sheds all liabilities in its
>CPS.
>
>*****
>
>"We strongly recommend securing all services with Public Key
>Infrastructure (PKI)" - well, that can cut one of two ways. If an
>organization is running its own PKI and *not* using the Internet
>profile, then the recommendation is sound. That is, the organization
>is not conferring trust. However, its a big problem with the Internet
>profile.
>
>We've seen a continual stream of failures when using a PKI under the
>Internet profile. In this case, the users expect end-to-end security
>but they are not getting it. We are conferring too much trust to
>untrustworthy actors, and we have to take additional steps to use it
>safely.
>
>*****
>
>"It is recommended that the OpenStack cloud architect rely on distinct
>sets of CAs" - what precisely is being recommended? It sounds like
>OpenStack is recommending two distinct PKIs - one for internal use
>(management network and internal service communications) and one for
>external use (external users ... public cloud endpoints). I suppose
>most importantly: the trusted roots in the PKIs should not
>cross-pollinate (ignoring different policies, revocation, etc).
>
>I think the confusion (for me) lies in framing it around "sets of
>CAs". For example, the Internet profile has a large set of CAs in an
>implementation - too many to count. But it's one PKI (give or take)
>with a number of implementations (Browsers, VPN clients, etc). I think
>you're really talking about PKIs.
>
>*****
>
>"...and the trusted set of public CA providers for ..." - "trust" is a
>funny word. If the word is going to be used, then it needs to be
>defined. One of the better definitions I have seen is "X trusts Y to
>do Z". However, if: X-> Relying Party, Y -> CA, Z -> Identify Servers
>or Services, then the statement becomes "Relying Party trusts CA to
>Identify Identify Servers or Services". That's a reasonable
>definition, a reasonable expectation, but not what the CAs provide
>(and the CA disclaims nearly all warranties and sheds all liabilities
>in its CPS).
>
>*****
>
>"...allowing external users to verify the identity of the public cloud
>endpoints" - take caution here. This *is* about identifying a server
>or service, but the CAs don't make those claims and don't warrant
>that. About all that is required to issue a certificate is a credit
>card that is accepted for payment and an email address. About all we
>know - as relying parties - is money may have changed hands at some
>time in the past.
>
>Extended Validation certificates are no better. They simply restore CA
>profit levels to 1990s levels. They add nothing of technical value.
>
>*****
>
>"... operators may wish to seek the advice of industry leaders and
>vendors..." - the vendors will "PKI you harder" (to borrow from Dr.
>Gutmann). That's kind of like asking a drunk if he's drunk - you're
>probably not going to get a good answer.
>
>*****
>
>"The SSL/TLS and HTTP services within OpenStack are typically
>implemented using OpenSSL which has been proven to be fairly secure" -
>is the guide talking about SST/TLS, HTTPS, OpenSSL, or a combination
>of them? Also, I believe the folks at Red Hat use NSS as the
>underlying crypto gear, and not OpenSSL.
>
>*****
>
>"We recommend only using TLS v1.1 or v1.2, but suggest SSLv3 and
>TLSv1.0 may be used for compatibility" - I question the suggestion or
>recommendation of SSLv3. Its 2013, and there's no reason to support it
>any longer.
>
>From Loren Weith's "Differences Between SSLv2 SSLv3 and TLS" (circa 1996):
>
>* It is possible to cause a key exchange algorithm rollback if the SSL
>connection is only attempting to provide authenticity services and not
>encryption[10].
>* Replay attacks on anonymous key exchange.
>* Known plaintexts are available to an attacker in certain portions of
>the protocol[10].
>* Ad-hoc use of message authentication codes.
>
>*****
>
>"We recommend..." - a few other thoughts...
>
>* anonymous key agreements should be used for forward secrecy
>* if using anonymous key agreements, then session resumption should be
>disabled
>* if offered, secure renegotiaion should be provided (and might
>prohibit use of TLSv1.0)
>* compression should be disabled if the threat model includes an
>attacker on the local LAN
>* TLS-SRP and TLS-PSK should be preferred since they properly bind the
>encryption tunnel with the inner authentication mechanism
>* practice certificate or public key pinning
>
>TLS-SRP and TLS-PSK are especially appealing. The user and server
>either share the secret or they do not. If they share the secret, the
>protocol will execute and succeed; otherwise, the protocol will fail.
>There's no need to ask CAs or DNS security related questions - there's
>no need to confer trust.
>
>*****
>
>From the OWASP Cheat Sheet: "The use of self signed certificates is
>never acceptable." - that's bad advice, and the damn browsers are not
>making it any better. Thought experiment:
>
>  Plain HTTP - good, no protection, no user warnings or feed back
>  Self-Signed HTTPS - bad, opportunistic encryption, lots of warnings and
>flags
>  CA Signed HTTPS - good, encryption, green bar
>
>How is plaintext HTTP better than self signed HTTPS? When and where
>did the security-IQs suddenly drop?
>
>How is CA Signed HTTPS better than Self-Signed HTTPS? Recall the CA
>signed cert is obtained from a vending machine and provides no
>assurances or warranty for the relying party at the time of use. They
>are equivalent for our technical purposes (and worse in some
>instances).
>
>*****
>
>Sorry about the verbosity. Brevity is not one of my strong suites.
>
>Jeffrey Walton
>Baltimore, MD, US
>
>_______________________________________________
>Openstack-security mailing list
>Openstack-security at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security