Jump to: navigation, search

Difference between revisions of "Neutron/LBaaS/SSL"

< Neutron‎ | LBaaS
(→‎Service Port (VIP listener) creation)
(→‎API change)
 
(137 intermediate revisions by the same user not shown)
Line 6: Line 6:
 
For giving LBaaS TLS termination ability, new extension called TLS will be added.
 
For giving LBaaS TLS termination ability, new extension called TLS will be added.
  
−
=== Rationale ===
+
===Overview===
 +
*Tenant will manage his TLS certificates using Barbican. Certificates will be stored in Barbican secure containers
 +
*Tenant will manage his TLS policies using Neutron. Policies will be stored in neutron schema
 +
*In addition to existing HTTP, HTTPS and TCP, new protocol, TLS will be added for VIP listener creation
 +
*For tenant, creating VIP listener with TLS as a protocol means desire to offload incoming encrypted traffic or/and encrypting outgoing traffic to the back-end servers.
  
−
The rational is giving user the ability to do TLS offload on LBaaS.
 
  
−
User should have the ability to configure the LBaaS to offload TLS traffic and encrypt it back while considering specific service ports (VIPs) and SNI
+
*When creating VIP listener with TLS protocol:
 +
** Not necessary to supply TLS policy - default behavior will be implemented, partly configurable in neutron configuration file:
 +
***Front-end TLS offloading enabled, back-end re-encryption disabled - hard coded as a default behavior in code
 +
***Front-end / Back-end supported protocols and cipher suites are listed in neutron configuration file. This is editable via neutron configuration file
 +
** If no policy associated and default behavior will take place - tenant must supply default TLS certificate for front-end offloading
 +
** If policy associated and the policy disables front-end offloading but enables back-end re-encryption - tenant must not supply default TLS certificate for front-end offloading
 +
** SNI certificates are not mandatory to specify
 +
** SNI certificates list specifying manner and treatment proposals are posted in "Proposals for SNI certificates list specifying and treating" section and should be discussed
 +
* Certificates chain for front-end certificates will be not be supported in this phase
 +
* Front-end client authentication and back-end server authentication will not be supported in this phase
  
−
Following are top level requirements
 
  
−
1st phase:
+
With stated above, following is a description of a basic tenant use case - creating VIP listener with TLS offloading:
−
*Tenant should be able to manage his TLS policies
+
*Creating VIP listener with TLS as a listener protocol
−
*Tenant should be able to manage his certificates and private keys, preferably via Barbican project API.
+
*Specifying default TLS certificate for front-end offloading by supplying Barbican's TLS certificate container ID
−
*Tenant should be able to apply TLS policy on specific service port (VIP listener)
+
As a result, VIP listener created, offloading encrypted traffic on front-end with default tenant's TLS certificate, not re-encrypting traffic to the back-end.
−
*Tenant should be able to associate TLS certificate/s to LBaaS' specific service port and to specific domain as well (SNI)
 
−
*Tenant should be able to configure the LBaaS to re-encrypt the traffic to the back-end
 
  
−
 
+
===Neutron LBaaS to Barbican API requirements===
−
2nd phase:
+
*need API for getting whole TLS certificate container, including private key, by container id
−
*Support certificates chain for front-end certificates
+
*need API for getting TLS certificates x.509 certificate
−
*Support front-end client authentication and back-end server authentication
 
  
 
=== User Experience ===
 
=== User Experience ===
−
==== TLS Policies Managing ====
 
−
Default policy will be available.
 
−
It will have front-end TLS termination enabled and back-end re-encryption disabled.
 
−
It's Front-end and back-end supported protocols and cipher suites should have most convenient default values
 
−
Tenant should be able to explore default policy details but should not be able to delete it.
 
  
−
Tenant will be able to "Add" (create), "Delete" (remove) and update TLS policies.
+
==== TLS Certificates Management====
 +
TLS certificates will be store in Barbican certificate containers that contain the TLS certificate itself and its private key.
 +
We should also examine the need to perform certificate sign requests using Barbican.
  
−
Cipher suites groups will be available: low, medium and high. A tenant will be able to choose one of them or to compile a customized list
+
Tenant will be able to create (add), delete (remove) and update TLS certificates using Barbican
  
−
=====On "Add", as usual, form pops-up with:=====
+
=====Creating TLS certificate (using Barbican)=====
 
*Name : text field
 
*Name : text field
 
*Description : text field
 
*Description : text field
−
*Enable Front-End termination : check box
+
*Certificate : PEM file name
−
*Front-End supported protocols : multiple selector (at least one should be selected)
+
*Private key: PEM file name (optional)
−
*Front-End supported cipher suites : Radio button with 4 choices:
+
*Pass phrase : text field (optional)
−
** LOW (OpenSSL LOW ciphers, Hint should show them all)
+
 
−
** MEDIUM (OpenSSL MEDIUM ciphers, Hint should show them all)
 
−
** HIGH (OpenSSL HIGH ciphers, Hint should show them all)
 
−
** All: (All cipher suites supported by the provider)
 
−
*Enable Back-End encryption : check box
 
−
*Back-End supported protocols : multiple selector (at least one should be selected)
 
−
*Back-End supported cipher suites : Radio button with 4 choices:
 
−
** LOW (OpenSSL LOW ciphers, Hint should show them all)
 
−
** MEDIUM (OpenSSL MEDIUM ciphers, Hint should show them all)
 
−
** HIGH (OpenSSL HIGH ciphers, Hint should show them all)
 
−
** All: (All cipher suites supported by the provider)
 
  
 +
===== Deleting TLS certificate (using Barbican)=====
 +
Preceded by confirmation.
 +
Certificates that are used by VIP listener/s can not be deleted
  
−
Note: Front-End or Back-End or both must be configured to SAVE.
+
=====Updating TLS certificate (using Brbican)=====
 +
*Only name and description may be modified
  
−
=====On "Delete", as usual, confirmation. Associated policies are deletion protected=====
+
Note: If changed certificate is associated with VIP listener(s), each back-end service provider (driver) should make any required changes
  
−
=====Following fields may be modified on policy update:=====
+
==== TLS Policies Management====
−
*all fields
 
  
−
Note: If changed policy is associated with one or more service ports (VIP listeners), each back-end service provider should perform any required changes
+
*TLS policies will be stored in neutron schema
 +
*Tenant will be able to "Add" (create), "Delete" (remove) and update TLS policies.
 +
*Default TLS policy behavior description:
 +
**Front-end offloading is enabled (hard-coded)
 +
**Default front-end supported protocols - SSL v3.0, TLS v1.0, TLS v1.2 (configurable via neutron configuration file)
 +
**Default front-end supported cipher suites - OpenSSL LOW cipher suite group (configurable via neutron configuration file)
 +
**Back-end re-encryption is disabled (hard-coded)
 +
**Default back-end supported protocols - SSL v3.0, TLS v1.0, TLS v1.2 (configurable via neutron configuration file)
 +
**Default back-end supported cipher suites - OpenSSL LOW cipher suite group (configurable via neutron configuration file)
 +
*The proposal is to use OpenSSL cipher suite groups (all, low, medium, high) as options to define cipher suites
 +
https://www.openssl.org/docs/apps/ciphers.html
 +
*('''TBD''') We may also give tenant an option to compile his own cipher suite group
  
−
==== TLS Certificates Managing ====
+
=====Creating TLS policy=====
−
Tenant will be able to create (add), delete (remove) and update TLS certificates
+
Note:
 +
1.Policy with both, front-end offloading and back-end re-encryption, disabled - is '''invalid'''
 +
2.When creating TLS policy ,default values for all parameters are derived from the
 +
  default TLS policy behavior (described above).
  
−
=====Following required for creation:=====
 
 
*Name : text field
 
*Name : text field
 
*Description : text field
 
*Description : text field
−
*Certificate : PEM file name
+
*Enable Front-End offloading : check box (requires default TLS certificate specification)
−
*Pass phrase : text field (optional)
+
*Enable Back-End encryption : check box
 +
*Front-End supported protocols : multiple selector from the list of options (SSL v3.0, TLS v1.0, TLS v1.2), at least one should be selected
 +
*Front-End supported cipher suites : Radio button with 4 choices:
 +
** ALL: (OpenSSL ALL ciphers group )
 +
** LOW (OpenSSL LOW ciphers group)
 +
** MEDIUM (OpenSSL MEDIUM ciphers group)
 +
** HIGH (OpenSSL HIGH ciphers group)
 +
*Back-End supported protocols : multiple selector from the list of options (SSL v3.0, TLS v1.0, TLS v1.2), at least one should be selected
 +
*Back-End supported cipher suites : Radio button with 4 choices (similar to front-end)
 +
 
 +
 
 +
=====Deleting TLS policy=====
 +
As usual, preceded by confirmation.
 +
Policy that is used by VIP listener(s) can not be deleted
 +
 
 +
=====Updating TLS policy=====
 +
*Only front-end and back-end protocols and cipher suite groups may be modified
 +
*Changing front-end offloading and back-end re-encryption functionality is not supported
 +
 
 +
Note: If changed policy is associated with VIP listener(s), each back-end service provider should perform any required changes
 +
 
 +
==== VIP listener creation ====
 +
 
 +
VIP listener has currently 3 protocols for choice (HTTP, HTTPS, TCP)
 +
New protocol is proposed - '''TLS''', which will be used to address cases of front end or/and back end encryption using certificates and policies.
 +
 
 +
=====VIP listener creation scenarios for TLS=====
 +
 
 +
By default, no TLS policy association required, default policy behavior described in overview section will take place.
 +
Tenant may associate TLS policy in order to get different behavior, but does not have to.
 +
Tenant must supply a default TLS certificate for front-end offloading if policy enabled front-end offloading.
 +
Tenant may supply a list of TLS certificates for SNI as well, but does not have to.
 +
 
 +
 
 +
=====Proposal for SNI certificates specifying and its treating by LBaaS provider=====
  
−
=====On "Delete", as usual, confirmation. Associated certificates are deletion protected=====
 
  
−
=====Following may be changed for existing certificate:=====
+
1. Ordered list of certificates.
−
*name
 
−
*description
 
  
−
Note: If changed certificate is associated with one or more service ports (listeners), each back-end service provider (driver) should make any required changes
+
Tenant will create list of TLS certificates and be able to control its order.
  
−
==== Service Port (VIP listener) creation ====
+
Choosing TLS certificate for incoming traffic offload will be done in following steps (until the first match):
  
−
*If service port (VIP listener) is created with HTTP protocol - no TLS configuration required / available.
+
*Scan the list, from first to last (top->bottom) and check if domain name exactly matches certificate's host name
−
Plain traffic is into front-end, L7 rulling available, plain traffic out to back-end server
+
*Scan the list, from first to last (top->bottom) and check if domain name matches certificate's host name regex
 +
*Scan the list, from first to last (top->bottom) and check if domain name matches one of certificate's alternative host names
 +
*No matches found? - use default certificate
  
  
−
*If service port (VIP listener) is created with HTTPS protocol - default TLS policy is attached to it.
+
2. List of certificates
−
Tenant may change the policy to different one.
 
−
TLS policy is actually defining the behavior of service port for incoming TLS traffic.
 
−
If policy enabled front-end termination - default TLS certificate will be associated required
 
  
−
==== VIP (listener) TLS Association ====
+
Tenant will create list of TLS certificates.
−
'''Important Note: Associating and disassociating TLS for a VIP are atomic actions.'''
 
−
'''TLS disassociating of a VIP will remove all associations with policy and certificates. This is relevant for UI and CLI.'''
 
  
−
On Project->Load Balancers screen, For each pool, "More" button->VIP TLS association(new) option, new form opens-up.
+
*Choosing TLS certificate for incoming traffic offload will be done by scanning the list until the first match
 +
*No matches found? - use default certificate
  
−
Single TLS policy may be selected from policies table, containing selection check box and policy name.
 
−
User will also be able to press the "Add New" button and get the TLS Policy addition form.
 
  
−
Depending on policy, if front-end termination is enabled, TLS certificates table will be enabled for choosing certificates.
+
3. List of (Certificate, list of (host names/patterns)):
 +
Example: '''(''' (amazon_cert_id, [*amazon.com, *amazon1.com]), (acme_cert_id, [acme.com]) ''')'''
  
−
TLS certificates table contains certificate name.
+
Tenant will create entries of TLS certificate and list of host name/s or host name patterns for this specific certificate.
  
−
At least one certificate must be selected.
+
Choosing TLS certificate for incoming traffic offload will be done in following steps (until the first match):
−
Also, "Add New" button will present. Pressing it will open the TLS certificate form.
 
  
−
*'''To apply an association:'''
+
*Scan the list, from first to last (top->bottom) and check if domain name matches one of host names/patterns
−
TLS policy must be selected. If front-end termination is enabled, at least one TLS certificate must be selected.
+
*No matches found? - use default certificate
 +
Note: this can not be supported by Radware LBaaS provider
  
−
==== VIP (listener) TLS Disassociation ====
+
==== VIP listener (with TLS protocol) updating ====
−
On disassociation of VIP and TLS, VIP and pool protocols will remain as is.
+
*TLS policy and certificates settings are available only for VIP listeners having TLS as a protocol
 +
*Changing TLS Policy for existing VIP listener is proposed to be deprecated because
 +
different policy may specify different behavior for front-end offloading and/or back-end re-encryption.
 +
This will require radical re-configuration of provider's back-end system, which seems to be not justified for this use case.
 +
Tenant, probably, should create new VIP listener with different TLS front-end offloading and back-end re-encryption settings.
  
 
=== API change ===
 
=== API change ===
−
*VIP (listener) CRUD API of the LBaaS plugin will not be changed.
+
*TLS policies CRUD will be added to LBaaS plugin API
−
*New extension named "tls" will be added, including TLS policies and certificates resources
+
*Since TLS offload functionality is a core LBaaS capability, VIP listener TLS settings API will be merged into the existing LBaaS plugin API
−
*New db extension named "tls_db" will be added, including TLS policies and certificates DB handling
 
−
*Since TLS offload capability is a core LBaaS capability, TLS entities management API and Vip TLS association API should be added to the LBaaS plugin
 
  
 
=== Resources change ===
 
=== Resources change ===
−
*VIP resource remains the same
 
  
−
*TLS policy (new)
+
*VIP listener resource will be modified with new:
−
**front-end-termination : bool
+
**TLS policy (optional)
−
**front-end-protocols : list of comma-separated values from a list of allowed values (SSLv3, TLSv1, TLSv1.1, TLSv1.2), default=None
+
**Default TLS certificate (optional)
−
**front-end-cipher_suites : list of coma-separated values from allowed values list.
+
**Associations link to SNI certificates list - SNI certificates will be saved in new associations table
 +
 
 +
 
 +
*TLS policy (new entity)
 +
**front-end-offloading : bool
 +
**front-end-protocols : list of comma-separated values from a list of allowed values (SSLv3, TLSv1, TLSv1.2), default=None
 +
**front-end-cipher_suites : list of coma-separated values
 
***Format - <key exchange algorithm>_<bulk encryption algorithm>_<message authentication code>_<pseudorandom function>
 
***Format - <key exchange algorithm>_<bulk encryption algorithm>_<message authentication code>_<pseudorandom function>
 
**back-end-encryption : bool
 
**back-end-encryption : bool
−
**back-end-protocols : list of comma-separated values from a list of allowed values (SSLv3, TLSv1, TLSv1.1, TLSv1.2), default=None
+
**back-end-protocols : <same format as front end>
−
**back-end-cipher_suites : list of coma-separated values from allowed values list.
+
**back-end-cipher_suites : <same format as front end>
−
***Format - <key exchange algorithm>_<bulk encryption algorithm>_<message authentication code>_<pseudorandom function>
 
−
**pass-info : list of coma-separated values from allowed values list (cipher, protocol, bits, front-end)
 
  
−
* TLS certificate (new)
+
=== Data model change ===
−
**certificate : PEM encoded X509 certificate
 
−
**pass_phrase : not mandatory string
 
−
**private_key : PEM encoded private key
 
−
**certificate_chain : list of PEM-formatted x509 certificates, not mandatory
 
  
−
=== Data model change ===
+
*VIP listener entity will be modified with new optional TLS policy and TLS default certificate fields.
−
*VIP (listener) entity will be associated with TLS policy and TLS certificate (s).
+
**tls_policy_id (string 36)
 +
**default_tls-certificate_id (string 36) - Barbican's certificate container id
  
−
*tls_policy (new)
 
−
tls_policy_id (string 36)
 
−
tls_policy_name (string 64)
 
−
front_end_enabled (bool)
 
−
front_end_protocols (string 32)
 
−
front_end_cipher_suites (string 512)
 
−
back_end_enabled (bool)
 
−
back_end_protocols (string 32)
 
−
back_end_cipher_suites (string 512)
 
−
pass_info (string 64)
 
  
−
*tls_certificate (new)
+
*tls_policy (new table)
−
tls-certificate_id (string 36)
+
**tls_policy_id (string 36)
−
tls-certificate-name (string 64)
+
**tls_policy_name (string 64)
−
certificate (string 4096)
+
**tls_policy_description (string 256)
−
pass_phrase (string 64)
+
**front_end_offloading (bool)
−
certificate_chain (string 20480)
+
**front_end_protocols (string 32)
−
private_key (string 4096) '''(absent in Icehouse release)'''
+
**front_end_cipher_suites (string 512)
 +
**back_end_encryption_enabled (bool)
 +
**back_end_protocols (string 32)
 +
**back_end_cipher_suites (string 512)
  
−
*vip_tls_policy_assoc (new, one policy per vip)
 
−
vip_id (string 36)
 
−
tls_policy_id (string 36)
 
−
status (string 16)
 
−
desc (string 255)
 
  
−
*vip_tls_certificate_assoc (new, multiple certificates per vip. certificate may be associated with multiple vips)
+
*vip_listener_sni_certificate_assoc - N:M (new associations table)
−
vip_id (string 36)
+
**vip_listener_id (string 36)
−
tls_certificate_id (string 36)
+
**tls_certificate_id (string 36)
−
status (string 16)
 
−
desc (string 255)
 
  
 
=== DB Migration ===
 
=== DB Migration ===
  
−
No DB migration is needed
+
DB migration is needed for:
 +
*VIP listener new columns - existing rows will be filled by null
 +
*New table for TLS policies
 +
*New table for SNI certificates associations to VIP listeners
 +
 
 +
=== CLI examples ===
 +
 
 +
*'''VIP listener creation''' with TLS protocol (default behavior)
  
−
=== CLI changes ===
+
lb-vip-listener-create --subnet-id <subnet-id> '''--protocol TLS''' --protocol-port 443
 +
'''--tls_default_certificate <barbican certificate container id>'''
 +
--name <name> [--address <address>] ...<usual CLI options>
  
−
===== SSL Policy =====
+
*'''VIP listener creation''' with TLS protocol and SNI certificates list (with TLS policy, front-end offloading enabled, back-end re-encryption enabled)
−
*neutron '''ssl-policy-create''' --front-end-termination type=dict enable=true protocols=SSLv3,TLSv1,TLSv1.1 cipher-suites=DES-CBC-SHA,EXP-DES-CBC-SHA --back-end-termination  type=dict enabled=true protocols=SSLv3,TLSv1,TLSv1.1 cipher-suites=DES-CBC-SHA,EXP-DES-CBC-SHA --pass-info type=dict cipher=true bits=true '''policy name'''
 
  
−
*neutron '''ssl-policy-update''' --policy_id --front-end-termination type-dict protocols=TLSv1,TLSv1.1
+
lb-vip-listener-create --subnet-id <subnet-id> '''--protocol TLS''' --protocol-port 443
 +
'''--tls_policy policy_with_front_end_offloading_enabled_id --tls_default_certificate <barbican certificate container id>'''
 +
'''--tls_sni_certificates certificate_1, certificate_2, certificate_3'''
 +
--name <name> [--address <address>] ...<usual CLI options>
  
−
*neutron '''ssl-policy-delete''' --policy_id
+
*'''VIP listener creation''' with TLS protocol (with TLS policy, front-end offloading disabled, back-end re-encryption enabled)
  
−
*neutron '''ssl-policy-list'''
+
lb-vip-listener-create --subnet-id <subnet-id> '''--protocol TLS''' --protocol-port 443
 +
'''--tls_policy policy_with_front_end_offloading_disabled_id'''
 +
--name <name> [--address <address>] ...<usual CLI options>
  
−
*neutron '''ssl-policy-show''' --policy_id
+
*'''TLS policy creation''' (both, front-end offloading and back-end re-encryption enabled)
 +
lb-tls-policy-create --front-end-termination type=dict enabled=true protocols=SSLv3,TLSv1,TLSv1.2 cipher-suites=DES-CBC-SHA,EXP-DES-CBC-SHA, ...
 +
--back-end-termination  type=dict enabled=true protocols=SSLv3,TLSv1,TLSv1.2 cipher-suites=DES-CBC-SHA,EXP-DES-CBC-SHA, ...
 +
'''MY_POLICY'''
  
−
===== SSL Certificate =====
+
−
*neutron '''ssl-certificate-create''' --cert CERTIFICATE-FILE <--private-key PRIVATE-KEY-FILE> <--passphrase PASSPHRASE> <--cert-chain INTERMEDIATE-CERT-FILE-1, INTERMEDIATE-CERT-FILE-2> '''certificate name'''
+
*'''Updating MY_POLICY policy with different protocols (no SSLv3)'''
 +
lb-tls-policy-update''' --policy_id MY_POLICY_ID --front-end-termination type-dict protocols=TLSv1,TLSv1.2 --back-end-termination  type=dict protocols=TLSv1,TLSv1.1
  
−
*neutron '''ssl-certificate-update''' --certificate-id --cert-chain INTERMEDIATE-CERT-FILE-1, INTERMEDIATE-CERT-FILE-2, INTERMEDIATE-CERT-FILE-3
+
*'''Deleting MY_POLICY'''
 +
lb-tls-policy-delete''' --policy_id MY_POLICY_ID
  
−
*neutron '''ssl-certificate-delete''' --certificate_id
+
*'''Listing policies'''
 +
lb-tls-policy-list'''
  
−
*neutron '''ssl-certificate-list'''
+
*'''Showing policy'''
 +
lb-tls-policy-show''' --policy_id
  
−
*neutron '''ssl-certificate-show''' --certificate_id
+
TLS certificates management will be available via Barbican CLI
  
−
===== Vip SSL Association =====
+
<To be expanded>
−
*neutron '''vip-ssl-associate''' --vip-id VIP-ID --ssl-policy-id my_policy_id --ssl-certificate type=dict certificate-id=google_cert_id private-key=PRIVATE-KEY-FILE-1 --ssl-trusted-certificate type=dict cert-id=KEY-ID-1
 
−
*neutron '''vip-ssl-disassociate''' --vip-id VIP-ID
 
−
TODO: List of certificates and trusted certificates should be supported
 
  
 
=== Implementation Plan ===
 
=== Implementation Plan ===
  
−
* Creating new extension called "ssl" with new SSL entities
+
* Creating new extension called "tls" with new TLS entities
−
* Add new SSL entities CRUD API to the LBaaS Plugin
+
* implement new TLS policy CRUD API to the LBaaS Plugin
−
* Add new DB entities and associations
+
* Implement changes in DB schema
−
* Add unit testing for new SSL extension's resources
+
* Implement unit testing for new TLS extension's resources
−
* Add unit testing for new SSL DB mixin
+
* Implement unit testing for new TLS DB mixin
−
* Modifying LBaaS HA-Proxy driver to support SSL extension
+
* Make integration with Barbican certificates storage API
 +
* Modifying LBaaS HA-Proxy driver to support TLS extension
 
* Update HA-Proxy to version 1.5 {TBD}
 
* Update HA-Proxy to version 1.5 {TBD}
  
Line 222: Line 267:
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
−
! Provider !! Protocols !! Cipher Suites !! Certificate chain !! FE client auth. !! BE trusted cert. !! BE client cert. !! SNI
+
! Provider !! Protocols !! Cipher Suites !! Certificate chain !! FE client auth. !! BE auth. !! SNI
 
|-
 
|-
−
| HAProxy 1.5 || SSLv3, TLSv1 || As OpenSSL || Yes || Yes || No ||  No || Yes
+
| HAProxy 1.5 || SSLv3, TLSv1 || As OpenSSL || Yes || No ||  No || Yes
 
|-
 
|-
−
| Amazon EC2 || SSLv2, SSLv3, TLSv1, TLSv1.1, TLSv1.2 || As OpenSSL || Yes || No || Yes || No || No
+
| Amazon EC2 || SSLv2, SSLv3, TLSv1, TLSv1.1, TLSv1.2 || As OpenSSL || No || Yes || No || No
 
|-
 
|-
−
| OpenStack || SSLv2, SSLv3, TLSv1, TLSv1.1, TLSv1.2 || As OpenSSL || Yes || No || Yes || No || Yes
+
| OpenStack || SSLv2, SSLv3, TLSv1, TLSv1.1, TLSv1.2 || As OpenSSL || phase 2 || phase 2 || phase 2 || Yes
 
|}
 
|}

Latest revision as of 11:15, 30 May 2014

Description

Terminating TLS connection on the load balancer and encrypting traffic back to the back end nodes, is a capabilities expected from modern load balancers and incorporated into many applications. This capability enables better certificate management and improved application based load balancing (ex: cookie based persistency, L7 Policies, etc.)

For giving LBaaS TLS termination ability, new extension called TLS will be added.

Overview

  • Tenant will manage his TLS certificates using Barbican. Certificates will be stored in Barbican secure containers
  • Tenant will manage his TLS policies using Neutron. Policies will be stored in neutron schema
  • In addition to existing HTTP, HTTPS and TCP, new protocol, TLS will be added for VIP listener creation
  • For tenant, creating VIP listener with TLS as a protocol means desire to offload incoming encrypted traffic or/and encrypting outgoing traffic to the back-end servers.


  • When creating VIP listener with TLS protocol:
    • Not necessary to supply TLS policy - default behavior will be implemented, partly configurable in neutron configuration file:
      • Front-end TLS offloading enabled, back-end re-encryption disabled - hard coded as a default behavior in code
      • Front-end / Back-end supported protocols and cipher suites are listed in neutron configuration file. This is editable via neutron configuration file
    • If no policy associated and default behavior will take place - tenant must supply default TLS certificate for front-end offloading
    • If policy associated and the policy disables front-end offloading but enables back-end re-encryption - tenant must not supply default TLS certificate for front-end offloading
    • SNI certificates are not mandatory to specify
    • SNI certificates list specifying manner and treatment proposals are posted in "Proposals for SNI certificates list specifying and treating" section and should be discussed
  • Certificates chain for front-end certificates will be not be supported in this phase
  • Front-end client authentication and back-end server authentication will not be supported in this phase


With stated above, following is a description of a basic tenant use case - creating VIP listener with TLS offloading:

  • Creating VIP listener with TLS as a listener protocol
  • Specifying default TLS certificate for front-end offloading by supplying Barbican's TLS certificate container ID

As a result, VIP listener created, offloading encrypted traffic on front-end with default tenant's TLS certificate, not re-encrypting traffic to the back-end.

Neutron LBaaS to Barbican API requirements

  • need API for getting whole TLS certificate container, including private key, by container id
  • need API for getting TLS certificates x.509 certificate

User Experience

TLS Certificates Management

TLS certificates will be store in Barbican certificate containers that contain the TLS certificate itself and its private key. We should also examine the need to perform certificate sign requests using Barbican.

Tenant will be able to create (add), delete (remove) and update TLS certificates using Barbican

Creating TLS certificate (using Barbican)
  • Name : text field
  • Description : text field
  • Certificate : PEM file name
  • Private key: PEM file name (optional)
  • Pass phrase : text field (optional)


Deleting TLS certificate (using Barbican)

Preceded by confirmation. Certificates that are used by VIP listener/s can not be deleted

Updating TLS certificate (using Brbican)
  • Only name and description may be modified
Note: If changed certificate is associated with VIP listener(s), each back-end service provider (driver) should make any required changes

TLS Policies Management

  • TLS policies will be stored in neutron schema
  • Tenant will be able to "Add" (create), "Delete" (remove) and update TLS policies.
  • Default TLS policy behavior description:
    • Front-end offloading is enabled (hard-coded)
    • Default front-end supported protocols - SSL v3.0, TLS v1.0, TLS v1.2 (configurable via neutron configuration file)
    • Default front-end supported cipher suites - OpenSSL LOW cipher suite group (configurable via neutron configuration file)
    • Back-end re-encryption is disabled (hard-coded)
    • Default back-end supported protocols - SSL v3.0, TLS v1.0, TLS v1.2 (configurable via neutron configuration file)
    • Default back-end supported cipher suites - OpenSSL LOW cipher suite group (configurable via neutron configuration file)
  • The proposal is to use OpenSSL cipher suite groups (all, low, medium, high) as options to define cipher suites

https://www.openssl.org/docs/apps/ciphers.html

  • (TBD) We may also give tenant an option to compile his own cipher suite group
Creating TLS policy
Note: 
1.Policy with both, front-end offloading and back-end re-encryption, disabled - is invalid
2.When creating TLS policy ,default values for all parameters are derived from the 
 default TLS policy behavior (described above).
  • Name : text field
  • Description : text field
  • Enable Front-End offloading : check box (requires default TLS certificate specification)
  • Enable Back-End encryption : check box
  • Front-End supported protocols : multiple selector from the list of options (SSL v3.0, TLS v1.0, TLS v1.2), at least one should be selected
  • Front-End supported cipher suites : Radio button with 4 choices:
    • ALL: (OpenSSL ALL ciphers group )
    • LOW (OpenSSL LOW ciphers group)
    • MEDIUM (OpenSSL MEDIUM ciphers group)
    • HIGH (OpenSSL HIGH ciphers group)
  • Back-End supported protocols : multiple selector from the list of options (SSL v3.0, TLS v1.0, TLS v1.2), at least one should be selected
  • Back-End supported cipher suites : Radio button with 4 choices (similar to front-end)


Deleting TLS policy

As usual, preceded by confirmation. Policy that is used by VIP listener(s) can not be deleted

Updating TLS policy
  • Only front-end and back-end protocols and cipher suite groups may be modified
  • Changing front-end offloading and back-end re-encryption functionality is not supported
Note: If changed policy is associated with VIP listener(s), each back-end service provider should perform any required changes

VIP listener creation

VIP listener has currently 3 protocols for choice (HTTP, HTTPS, TCP) New protocol is proposed - TLS, which will be used to address cases of front end or/and back end encryption using certificates and policies.

VIP listener creation scenarios for TLS

By default, no TLS policy association required, default policy behavior described in overview section will take place. Tenant may associate TLS policy in order to get different behavior, but does not have to. Tenant must supply a default TLS certificate for front-end offloading if policy enabled front-end offloading. Tenant may supply a list of TLS certificates for SNI as well, but does not have to.


Proposal for SNI certificates specifying and its treating by LBaaS provider

1. Ordered list of certificates.

Tenant will create list of TLS certificates and be able to control its order.

Choosing TLS certificate for incoming traffic offload will be done in following steps (until the first match):

  • Scan the list, from first to last (top->bottom) and check if domain name exactly matches certificate's host name
  • Scan the list, from first to last (top->bottom) and check if domain name matches certificate's host name regex
  • Scan the list, from first to last (top->bottom) and check if domain name matches one of certificate's alternative host names
  • No matches found? - use default certificate


2. List of certificates

Tenant will create list of TLS certificates.

  • Choosing TLS certificate for incoming traffic offload will be done by scanning the list until the first match
  • No matches found? - use default certificate


3. List of (Certificate, list of (host names/patterns)): Example: ( (amazon_cert_id, [*amazon.com, *amazon1.com]), (acme_cert_id, [acme.com]) )

Tenant will create entries of TLS certificate and list of host name/s or host name patterns for this specific certificate.

Choosing TLS certificate for incoming traffic offload will be done in following steps (until the first match):

  • Scan the list, from first to last (top->bottom) and check if domain name matches one of host names/patterns
  • No matches found? - use default certificate
Note: this can not be supported by Radware LBaaS provider

VIP listener (with TLS protocol) updating

  • TLS policy and certificates settings are available only for VIP listeners having TLS as a protocol
  • Changing TLS Policy for existing VIP listener is proposed to be deprecated because

different policy may specify different behavior for front-end offloading and/or back-end re-encryption. This will require radical re-configuration of provider's back-end system, which seems to be not justified for this use case. Tenant, probably, should create new VIP listener with different TLS front-end offloading and back-end re-encryption settings.

API change

  • TLS policies CRUD will be added to LBaaS plugin API
  • Since TLS offload functionality is a core LBaaS capability, VIP listener TLS settings API will be merged into the existing LBaaS plugin API

Resources change

  • VIP listener resource will be modified with new:
    • TLS policy (optional)
    • Default TLS certificate (optional)
    • Associations link to SNI certificates list - SNI certificates will be saved in new associations table


  • TLS policy (new entity)
    • front-end-offloading : bool
    • front-end-protocols : list of comma-separated values from a list of allowed values (SSLv3, TLSv1, TLSv1.2), default=None
    • front-end-cipher_suites : list of coma-separated values
      • Format - <key exchange algorithm>_<bulk encryption algorithm>_<message authentication code>_<pseudorandom function>
    • back-end-encryption : bool
    • back-end-protocols : <same format as front end>
    • back-end-cipher_suites : <same format as front end>

Data model change

  • VIP listener entity will be modified with new optional TLS policy and TLS default certificate fields.
    • tls_policy_id (string 36)
    • default_tls-certificate_id (string 36) - Barbican's certificate container id


  • tls_policy (new table)
    • tls_policy_id (string 36)
    • tls_policy_name (string 64)
    • tls_policy_description (string 256)
    • front_end_offloading (bool)
    • front_end_protocols (string 32)
    • front_end_cipher_suites (string 512)
    • back_end_encryption_enabled (bool)
    • back_end_protocols (string 32)
    • back_end_cipher_suites (string 512)


  • vip_listener_sni_certificate_assoc - N:M (new associations table)
    • vip_listener_id (string 36)
    • tls_certificate_id (string 36)

DB Migration

DB migration is needed for:

  • VIP listener new columns - existing rows will be filled by null
  • New table for TLS policies
  • New table for SNI certificates associations to VIP listeners

CLI examples

  • VIP listener creation with TLS protocol (default behavior)
lb-vip-listener-create --subnet-id <subnet-id> --protocol TLS --protocol-port 443 
--tls_default_certificate <barbican certificate container id> 
--name <name> [--address <address>] ...<usual CLI options>
  • VIP listener creation with TLS protocol and SNI certificates list (with TLS policy, front-end offloading enabled, back-end re-encryption enabled)
lb-vip-listener-create --subnet-id <subnet-id> --protocol TLS --protocol-port 443 
--tls_policy policy_with_front_end_offloading_enabled_id --tls_default_certificate <barbican certificate container id>
--tls_sni_certificates certificate_1, certificate_2, certificate_3
--name <name> [--address <address>] ...<usual CLI options>
  • VIP listener creation with TLS protocol (with TLS policy, front-end offloading disabled, back-end re-encryption enabled)
lb-vip-listener-create --subnet-id <subnet-id> --protocol TLS --protocol-port 443 
--tls_policy policy_with_front_end_offloading_disabled_id
--name <name> [--address <address>] ...<usual CLI options>
  • TLS policy creation (both, front-end offloading and back-end re-encryption enabled)
lb-tls-policy-create --front-end-termination type=dict enabled=true protocols=SSLv3,TLSv1,TLSv1.2 cipher-suites=DES-CBC-SHA,EXP-DES-CBC-SHA, ... 
--back-end-termination  type=dict enabled=true protocols=SSLv3,TLSv1,TLSv1.2 cipher-suites=DES-CBC-SHA,EXP-DES-CBC-SHA, ...
MY_POLICY


  • Updating MY_POLICY policy with different protocols (no SSLv3)
lb-tls-policy-update --policy_id MY_POLICY_ID --front-end-termination type-dict protocols=TLSv1,TLSv1.2 --back-end-termination  type=dict protocols=TLSv1,TLSv1.1
  • Deleting MY_POLICY
lb-tls-policy-delete --policy_id MY_POLICY_ID
  • Listing policies
lb-tls-policy-list
  • Showing policy
lb-tls-policy-show --policy_id

TLS certificates management will be available via Barbican CLI

<To be expanded>

Implementation Plan

  • Creating new extension called "tls" with new TLS entities
  • implement new TLS policy CRUD API to the LBaaS Plugin
  • Implement changes in DB schema
  • Implement unit testing for new TLS extension's resources
  • Implement unit testing for new TLS DB mixin
  • Make integration with Barbican certificates storage API
  • Modifying LBaaS HA-Proxy driver to support TLS extension
  • Update HA-Proxy to version 1.5 {TBD}

Support Matrix

Provider Protocols Cipher Suites Certificate chain FE client auth. BE auth. SNI
HAProxy 1.5 SSLv3, TLSv1 As OpenSSL Yes No No Yes
Amazon EC2 SSLv2, SSLv3, TLSv1, TLSv1.1, TLSv1.2 As OpenSSL No Yes No No
OpenStack SSLv2, SSLv3, TLSv1, TLSv1.1, TLSv1.2 As OpenSSL phase 2 phase 2 phase 2 Yes
Retrieved from "https://wiki.openstack.org/w/index.php?title=Neutron/LBaaS/SSL&oldid=54284"