Open Stack

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