64b6c9261e
Current folder name New folder name Book title ---------------------------------------------------------- basic-install DELETE cli-guide DELETE common common NEW admin-guide-cloud Cloud Administrators Guide docbkx-example DELETE openstack-block-storage-admin DELETE openstack-compute-admin DELETE openstack-config config-reference OpenStack Configuration Reference openstack-ha high-availability-guide OpenStack High Availabilty Guide openstack-image image-guide OpenStack Virtual Machine Image Guide openstack-install install-guide OpenStack Installation Guide openstack-network-connectivity-admin admin-guide-network OpenStack Networking Administration Guide openstack-object-storage-admin DELETE openstack-security security-guide OpenStack Security Guide openstack-training training-guide OpenStack Training Guide openstack-user user-guide OpenStack End User Guide openstack-user-admin user-guide-admin OpenStack Admin User Guide glossary NEW OpenStack Glossary bug: #1220407 Change-Id: Id5ffc774b966ba7b9a591743a877aa10ab3094c7 author: diane fleming
86 lines
8.9 KiB
XML
86 lines
8.9 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
||
<chapter xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://docbook.org/ns/docbook" xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="ch017_threat-models-confidence-and-confidentiality"><?dbhtml stop-chunking?>
|
||
<title>Introduction to SSL/TLS</title>
|
||
<para>OpenStack services receive requests on behalf of users on public networks as well as from other internal services over management networks. Inter-service communications can also occur over public networks depending on deployment and architecture choices.</para>
|
||
<para>While it is commonly accepted that data over public networks should be secured using cryptographic measures, such as Secure Sockets Layer or Transport Layer Security (SSL/TLS) protocols, it is insufficient to rely on security domain separation to protect internal traffic. Using a security-in-depth approach, we recommend securing all domains with SSL/TLS, including the management domain services. It is important that should a tenant escape their VM isolation and gain access to the hypervisor or host resources, compromise an API endpoint, or any other service, they must not be able to easily inject or capture messages, commands, or otherwise affect or control management capabilities of the cloud. SSL/TLS provides the mechanisms to ensure authentication, non-repudiation, confidentiality, and integrity of user communications to the OpenStack services and between the OpenStack services themselves.</para>
|
||
<para>Public Key Infrastructure (PKI) is the set of hardware, software, and policies to operate a secure system which provides authentication, non-repudiation, confidentiality, and integrity. The core components of PKI are:</para>
|
||
<itemizedlist><listitem>
|
||
<para>End Entity - user, process, or system that is the subject of a certificate</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Certification Authority (<glossterm>CA</glossterm>) - defines certificate policies, management, and issuance of certificates</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Registration Authority (RA) - an optional system to which a CA delegates certain management functions</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Repository - Where the end entity certificates and certificate revocation lists are stored and looked up - sometimes referred to as the "certificate bundle"</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Relying Party - The end point that is trusting that the CA is valid.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
<para>PKI builds the framework on which to provide encryption algorithms, cipher modes, and protocols for securing data and authentication. We strongly recommend securing all services with Public Key Infrastructure (PKI), including the use of SSL/TLS for API endpoints. It is impossible for the encryption or signing of transports or messages alone to solve all these problems. Hosts themselves must be secure and implement policy, namespaces, and other controls to protect their private credentials and keys. However, the challenges of key management and protection do not reduce the necessity of these controls, or lessen their importance.</para>
|
||
<section xml:id="ch017_threat-models-confidence-and-confidentiality-idp51264">
|
||
<title>Certification Authorities</title>
|
||
<para>Many organizations have an established Public Key Infrastructure with their own certification authority (CA), certificate policies, and management for which they should use to issue certificates for internal OpenStack users or services. Organizations in which the public security domain is Internet facing will additionally need certificates signed by a widely recognized public CA. For cryptographic communications over the management network, it is recommended one not use a public CA. Instead, we expect and recommend most deployments deploy their own internal CA.</para>
|
||
<para>It is recommended that the OpenStack cloud architect consider using separate PKI deployments for internal systems and customer facing services. This allows the cloud deployer to maintain control of their PKI infrastructure and among other things makes requesting, signing and deploying certificates for internal systems easier. Advanced configurations may use separate PKI deployments for different security domains. This allows deployers to maintain cryptographic separation of environments, ensuring that certificates issued to one are not recognised by another.</para>
|
||
<para>Certificates used to support SSL/TLS on internet facing cloud endpoints (or customer interfaces where the customer is not expected to have installed anything other than standard operating system provided certificate bundles) should be provisioned using Certificate Authorities that are installed in the operating system certificate bundle. Typical well known vendors include Verisign and Thawte but many others exist.</para>
|
||
<para>There are many management, policy, and technical challenges around creating and signing certificates as such is an area where cloud architects or operators may wish to seek the advice of industry leaders and vendors in addition to the guidance recommended here.</para>
|
||
</section>
|
||
<section xml:id="ch017_threat-models-confidence-and-confidentiality-idp55136">
|
||
<title>SSL/TLS Libraries</title>
|
||
<para>Various components, services, and applications within the OpenStack ecosystem or dependencies of OpenStack are implemented and can be configured to use SSL/TLS libraries. The SSL/TLS and HTTP services within OpenStack are typically implemented using OpenSSL which has been proven to be fairly secure and has a module that has been validated for FIPS 140-2. However, keep in mind that each application or service can still introduce weaknesses in how they use the OpenSSL libraries.</para>
|
||
</section>
|
||
<section xml:id="ch017_threat-models-confidence-and-confidentiality-idp56784">
|
||
<title>Cryptographic Algorithms, Cipher Modes, and Protocols</title>
|
||
<para>We recommend only using TLS v1.1 or v1.2. SSLv3 and TLSv1.0 may be used for compatibility but we recommend using caution and only enabling these protocols if you have a strong requirement to do so. Other SSL/TLS versions, explicitly older versions, should not be used. These older versions include SSLv1 and SSLv2. As this book does not intend to be a thorough reference on cryptography we do not wish to be prescriptive about what specific algorithms or cipher modes you should enable or disable in your OpenStack services. However, there are some authoritative references we would like to recommend for further information:</para>
|
||
<itemizedlist><listitem>
|
||
<para><link xlink:href="http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml">National Security Agency, Suite B Cryptography</link></para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><link xlink:href="https://www.owasp.org/index.php/Guide_to_Cryptography">OWASP Guide to Cryptography</link></para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><link xlink:href="https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet">OWASP Transport Layer Protection Cheat Sheet</link></para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><link xlink:href="http://www.ieee-security.org/TC/SP2013/papers/4977a511.pdf">SoK: SSL and HTTPS: Revisiting past challenges and evaluating certificate trust model enhancements</link></para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><link xlink:href="http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf">The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software</link></para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><link xlink:href="http://www.openssl.org/docs/fips/fipsnotes.html">OpenSSL and FIPS 140-2</link></para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</section>
|
||
<section xml:id="ch017_threat-models-confidence-and-confidentiality-idp64128">
|
||
<title>Summary</title>
|
||
<para>Given the complexity of the OpenStack components and the number of deployment possibilities, you must take care to ensure that each component gets the appropriate configuration of SSL certificates, keys, and CAs. The following services will be discussed in later sections of this book where SSL and PKI is available (either natively or possible via SSL proxy):</para>
|
||
<itemizedlist><listitem>
|
||
<para>Compute API endpoints</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Identity API endpoints</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Networking API endpoints</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Storage API endpoints</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Messaging server</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Database server</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Dashboard</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
<para>Throughout this book we will use SSL as shorthand to refer to these recommendations for SSL/TLS protocols.</para>
|
||
</section>
|
||
</chapter>
|