Features and Terminology in F5 Guided Configuration for SSL Orchestrator

Features in SSL Orchestrator 9.0

Session Abort Ending for blocked TLS session
The SSL Orchestrator security policy contains a new abort option as a blocking action.
SNI based Bypass based on client Hello
The security policy can now be configured to bypass TLS decryption based on SNI received in Client Hello, and before any server-side evaluation. In previous versions a connection would break in scenarios where TLS bypass by unique SNI/host was required for mutual TLS authentication. The elements of the security policy that perform this evaluation required a server-side “look”, which would then break on the server side due to the client certificate requirement. In 9.0, a TLS bypass can be created, by SNI/host name, that will not break TLS.
Support authorityKeyIdentifier (AKI) extension for certificates
SSL Orchestrator now includes an AKI in the forged server certificate to aid in the certificate path discovery at the client. Path discovery is the mechanism that a TLS client performs to find and build a complete chain of trust from the end-entity (leaf) certificate to the explicitly trusted root CA. In previous versions, the client would need to perform certificate path discover based on subject and issuer common name string values, where the issuer name in a child certificate matches the subject name in the issuer certificate, and continued up to the self-signed root CA. This can cause issues in scenarios where a CA root certificate is “cross-signed” with another authority, creating two versions of the CA (a self-signed and issued certificate with the same common name). The AKI and subjectKeyIdentifier (SKI) values are a SHA hash of a unique public key, making path discovery more reliable. In this case, instead of using subject and issuer string names, the AKI value in the leaf certificate will match the SKI of its parent, and continued up to the self-signed root CA.
SSL Profile Switching and wildcard domain name matching from ClientHello SNI (EA)
This feature will allow an outbound topology to switch its SSL profiles based on client hello SNI matches. The most common use cases here might be switching a CA issuer for different tenants, or bypassing TLS for mutual sessions by SNI host name.
SSL Orchestrator support for local OCSP Responder
SSL Orchestrator now supports a local OCSP certificate revocation responder service for forged server certificates. The forged certificates can contain an authorityInfoAccess (AIA) attribute that points to a locally defined URL (a listening service on BIG-IP) that provides OCSP revocation status on the forged certificates.
Send SSL session logs using log publisher to one or more log destination
SSL Orchestrator can now log the details of the forged server certificate, and pass that to external log consumers via log publishers. This required STIP (CC) mode to be enabled in order for TMM to generate SSL session logs.
SSL Orchestrator to intercept HTTP/2 without demultiplexing
SSL Orchestrator now supports full-proxy HTTP/2 through the decrypted service chain. This is a “phase feature where HTTP/2 is not de-multiplexed, so security must also support decrypted HTTP/2. In phase 2, SSL Orchestrator will be able to de-mux to HTTP/1.1 inside the service chain.
Verified Accept Support in SSL Orchestrator
When enabled, the system verifies that the pool member is available to accept the connection by sending the server a SYN before responding to the client’s SYN with a SYN-ACK packet. SSL Orchestrator topologies are built on a standard virtual server type (with Verified Accept disabled). This could cause an issue in the scenario where an upstream firewall might block a specific IP and/or port, but the SSL Orchestrator closer to the client allows the connection (only to be blocked later at the firewall). Enabling Verified Accept allows the F5 to test for a valid server-side connection before completing the client-side handshake.
SSL Orchestrator Tabbed Service Catalog
The security products in the SSL Orchestrator service Catalog are now represented in a new de-cluttered tabbed interface, separated as inline layer 2, inline layer3, inline HTTP, ICAP, TAP, and a new F5 services tab. The F5 services tab will initially included SWG, but will eventually contain other F5 offerings, including WAF, tenant restrictions, IPS, and others.
SSL Orchestrator apply address a/r port-lists to in/out topo Guided Setup
SSL Orchestrator now supports lists and port lists in the Guided Configuration. This will allow for more granular IP/port control over traffic intercept conditions.
SSL Orchestrator Control Plane Re- architecture
Control plane re-architecture (source-of-truth and HA improvements): Significant improvements have come to the SSL Orchestrator control plane. In previous versions, the source-of-truth for the SSL Orchestrator configuration is JSON block storage (file-system objects). This separate source-of-truth (vs. native MCP configuration state) has created challenges, including some instability, configuration latency, and HA issues. In 9.0 the source-of-truth is still in separate JSON format, but now stored in iFile objects. This change allows SSL Orchestrator to utilized native MCP/CMI HA sync functions, and thus allows it to now support native automatic and incremental sync.
Control plane re- architecture (removal of UI strictness): iApp strictness has always been a challenge in the SSL Orchestrator solution, at times making out-of-changes either complex, or impossible. In 9.0, the strictness lock icon has been removed from most objects, allowing you to freely make out-of-band changes that are honored by the SSL Orchestrator configuration throughout management and upgrade. The only significant object to retain strictness is the security policy, as moving between a constrained security policy ruleset and unconstrained visual policy editor would be untenable to manage.
Control plane re-architecture (Gossip removal): Gossip is the process whereby the SSL Orchestrator communications HA sync information to its peer. This information is bidirectional and independent of typical BIG-IP “CMI” sync functions. In previous versions, gossip has proven to be an issue, particularly when configurations fail. In this release, the gossip sync function is removed and replaced with a new sync option (see source-of-truth update below).
SSL Orchestrator to have per topology DNS setting
Explicit proxy topologies can now define independent DNS resolver settings.
SSL Orchestrator pool members change from 6 to 20 with Standalone license
SSL Orchestrator Standalone licensing has always limited the number of service pool members to 6 devices. This licensing update increases that number to 20.

Other SSL Orchestrator Features and Terminology

Certificate Authority (CA) certificate
This implementation requires a Certificate Authority PKI (public key infrastructure) certificate and matching private key for SSL Forward Proxy. Your TLS clients must trust this CA certificate to sign server certificates.
Inspection zone
An inspection zone refers to the network region between separate ingress and egress BIG-IP® devices where cleartext data is available for inspection. Basically, an extra inline service can be placed at the end of every service chain for additional inspection. You cannot configure a decrypt zone in the scenario where a single BIG-IP system handles both ingress and egress traffic because the inspection zone does not exist.
F5 Guided Configuration for SSL Orchestrator
F5 Guided Configuration for SSL Orchestrator is meant to guide you through setting up a particular use case on the SSL Orchestrator system. Each template requests minimal input and provides contextual help to assist users during setup.
The current version displays on the landing page. When a later upgrade becomes available, you can use the available link next to the version number to download it from devcentral.f5.com, then upload and install it Guided Configuration for SSL Orchestrator link.
To go to the landing page, save any work you have done in the right pane before you click
SSL Orchestrator
Configuration
, or click the
Home
icon in the menu steps.
See the
Setting up F5 Guided Configuration for SSL Orchestrator
section for detailed steps on installing and upgrading to the newest version.
HTTP services
You can configure inline HTTP explicit proxy (EP) or transparent proxy (TP) settings with SSL Orchestrator configured as either an explicit or transparent proxy for extended SSL visibility and existing or new deployments. Using SSL Orchestrator, the inline proxy device can be in either transparent or explicit mode, irrespective of SSL Orchestrator's mode.
ICAP services
Each ICAP service uses the ICAP protocol (https://tools.ietf.org/html/rfc3507) to refer HTTP traffic to one or more Content Adaptation device(s) for inspection and possible modification. You can add an ICAP service to any TCP service chain, but only HTTP traffic is sent to it, as we do not support ICAP for other protocols. You can configure up to ten ICAP services using F5® SSL Orchestrator™.
Layer 2 (L2) and Layer 3 (L3) inline services
Inline services pass traffic through one or more service (inspection) devices at Layer2 (MAC)/Bump-in-the-wire or Layer3 (IP). Each service device communicates with the SSL Orchestrator device over two VLANs called
Inward
and
Outward
which carry traffic toward the intranet and the Internet respectively. You can configure up to ten inline services, each with multiple defined devices, using SSL Orchestrator.
Receive-only/TAP services
Receive-only services refer to services that only receive traffic for inspection, and do not send it back to the BIG-IP system. Each receive-only service provides a packet-by-packet copy of the traffic (e.g. plaintext) passing through it to an inspection device. You can configure up to ten receive-only services using SSL Orchestrator.
Security policies
The SSL Orchestrator uses a visual per-request policy engine, or Visual Policy Editor (VPE), to define traffic flows through the security services. Security policies are available within the VPE with each element, or box, representing a corresponding macro whose information (and output) influences the next element and its macro, until the traffic is either allowed or blocked.
Service chains
SSL Orchestrator service chains process specific connections based on rules which look at protocol, source and destination addresses, and so on. These service chains can include five types of services (HTTP services, Layer 2 inline services, Layer 3 inline services, receive-only/TAP services, and ICAP services) you define, as well as any decrypt zone between separate ingress and egress devices.
SNAT
A SNAT (Secure Network Address Translation) is a feature that defines routable alias IP addresses that the BIG-IP system substitutes for client IP source addresses when making connections to hosts on the external network. A SNAT pool is a pool of translation addresses that you can map to one or more original IP addresses. Translation addresses in a SNAT pool should not be self IP addresses.
Strict Update option (Protected/Unprotected Configurations)
By selecting the strict update option (on the Guided Configuration Welcome screen in a column labelled
Protected/Unprotected Configurations
) for deployed configurations, you cannot manually modify any settings produced by the application. Once you disable this option (click on the lock symbol), you can manually change your configuration. F5 recommends you keep this setting enabled (locked) to avoid misconfigurations that can result in an unusable application and limit F5's ability to support your product. The strict update check box is enabled/selected by default.
Sync-Failover device group
A Sync-Failover device group (part of the Device Service Clustering (DSC®) functionality) contains BIG-IP devices that synchronize their configuration data and failover to one another when a device becomes unavailable. In this configuration, a Sync-Failover device group supports a maximum of two devices.
Transparent/Explicit proxy
You can operate in transparent and/or explicit proxy mode. A transparent proxy intercepts normal communication without requiring any special client configuration; clients are unaware of the proxy in the network. In this implementation, the transparent proxy scheme can intercept all types of TLS and TCP traffic. It can also process UDP and forward other types of IP traffic. The explicit proxy scheme supports only HTTP(S) per RFC2616. In addition, transparent proxy supports direct routing for policy-based routing (PBR) and Web Cache Communication Protocol (WCCP) that are dependent on networking services to support both protocols, while explicit proxy supports manual browser settings for proxy auto-config (PAC) and Web Proxy Autodiscovery Protocol (WPAD) that require additional iRule configurations (not included) to provide the PAC/WPAD script content.

Topologies (Guided Configuration Steps)

Topology
When using the Topology screen, you can set up SSL Orchestrator in an array of topologies that define the type of traffic (transparent or explicit) and the direction of traffic flow (inbound or outbound) you wish to inspect.
These deployment settings, which can be modified as needed without un-deploying a configuration, are complimented by SSL settings that assist you in defining inbound and outbound decryption, setting your service types (such as HTTP, ICAP, Layer 2 (L2)/Layer 3 (L3) inline, and receive-only/TAP services), creating your service chains and security policies that can be managed through a visual policy editor.
Available topologies are based on your initial network setup. Topologies that are not supported by your network setup or licensing will not show as an enabled option.
L2 Inbound
and
L2 Outbound
topologies are only available for supported L2 wire enabled networks.
L3 Inbound
and
L3 Outbound
topologies are available for all supported networks.
L3 Explicit Proxy
topology is only available when Protocol is set to either TCP or Any.
Existing Application
topology is available for SSL Orchestrator addon licensed devices. This option is not available for standalone SSL Orchestrator devices.
SSL Orchestrator provides the installation of default or custom outbound interception rules for greater support in defining your listeners and the flexibility to create your own outbound and inbound interception rules.
SSL Configuration
When configuring the SSL Configuration screen, you can set up or manage your forward proxy (for outbound traffic) or reverse proxy (for inbound traffic) scenarios by creating a new SSL profile or selecting an existing SSL profile you have previously created. In addition, you can attach multiple SSL profiles to the same virtual for both inbound and outbound topologies. You can also switch SSL profile based on ClientHello SNI matches. For this, specify the server name used for SNI communications and select the
Default SNI
checkbox in the SSL profile that the system should consider as the default profile. You can only use one such SSL Configuration in a Topology.
You can setup and manage client and server cipher types (group or string), and select certificate, key, and chain configuration details required to process SSL traffic.
For outbound scenarios, click
Show Advanced Setting
to see an option to enable or disable SSL forward proxy bypass on receiving a handshake failure, protocol version, or unsupported extension alert message during the server-side SSL handshake so that SSL traffic bypasses the BIG-IP system untouched, without decryption/encryption.
You can enable or disable SSL forward proxy bypass when failing to get a client certificate that the server asks for so that SSL traffic bypasses the BIG-IP system untouched, without decryption/encryption.
For outbound and inbound scenarios, you can also control whether SSL Orchestrator should ignore/drop untrusted/expired server certificates. Additionally, you can specify an OCSP responder or a CRL file to validate server certificates.
Authenication
You can configure a Local Online Certificate Status Protocol (OCSP) Responder and associate a Local OCSP Responder to a virtual server (which is part of the UI). OCSP is an Internet protocol used to obtain the revocation status of a digital certificate. When the validity of a certificate is requested, an OCSP request is sent to an OCSP Responder and checks the specific certificate with a trusted certificate authority. This results in an OCSP response being sent back of good, revoked, or unknown.
To configure Authentication, you must select
TCP
or
Any
as your Protocol and either
L2 Outbound
,
L3 Outbound
, or
L3 Explicit Proxy
as your SSL Orchestrator topology from the Topology Properties screen. If you do not select one of the required protocols or topologies, Authentication will not be supported or appear as a Guided Configuration step.
To create a new authentication, click
Add
. The Authentication Properties screen appears where you can select OCSP Responder (for the Client). Click
OCSP Responder
and click
Add
. The Authentication Properties screen appears where you can configure a new OCSP Responder.
You may also edit or delete a newly created authentication that is a part of your current workflow and that has not yet been deployed. These configurations will show
NOT DEPLOYED
next to the authentication name.
.
Previously deployed authentications that are listed cannot be deleted or edited and belong to deployed global authentications.
Click
Show Advanced Setting
to select the following Protocol Settings:
Client TCP Profile
,
Server TCP Profile
,
HTTP Profile
.
Optional
: Later, when configuring the Interception Rule, you may select from the Authentication section OCSP Responder list to associate a Local OCSP Responder into the Interception Rule. This action adds a new iRule to the virtual server. In addition, you may configure authentication using the mini-flow Authentication tab without creating a topology and may utilize the existing iRule item-selector to select the OCSP iRule.
Service
When configuring the Service screen, you can create services such as HTTP, ICAP, Layer 2 and Layer 3 inline, receive only TAP, and other services.
HTTP Services
: You can configure inline HTTP explicit or transparent proxy settings with SSL Orchestrator configured as either an explicit or transparent proxy for extended SSL visibility and existing or new deployments. Using SSL Orchestrator, you can support multiple explicit and transparent proxy configurations such as: SSLO Explicit proxy with in-line explicit proxy as a service (EP-EP); SSLO Transparent proxy with in-line explicit proxy as a service (TP-EP); SSLO Explicit proxy with in-line transparent proxy as a service (EP-TP); SSLO Transparent proxy with in-line transparent proxy as a service (TP-TP).
ICAP
: Each ICAP service uses the Internet Content Adaptation Protocol (ICAP) RFC3507 protocol to refer HTTP traffic to one or more Content Adaptation devices for inspection and possible modification. You can configure the ICAP services that are a part of this configuration.
Layer 2 and Layer 3 inline
: Inline services pass traffic through one or more service devices at Layer 2 (LAN) or Layer 3 (IP). Each service device communicates with the BIG-IP device on the ingress side over two VLANs called Inward and Outward that carry traffic toward the intranet and the Internet, respectively.
Receive Only TAP
: TAP services only receive traffic for inspection, and do not send it back to the BIG-IP system. Each receive-only service provides a packet-by-packet copy of the traffic (for example, plaintext), passing through it to an inspection device.
To use a previously created service, select the check box next to the name of the desired service type and click
Save & Next
. You can edit any previously created service by clicking directly on the name. To create a new service, click
Add Service
.
Only the services created as part of this workflow can be deleted.
Service Chain
When configuring the Service Chain screen, you can process specific connections based on security policy rules which look at protocol, source, and destination addresses to define an ordered list of services. These service chains can include an ordered list of services you define, as well as any decrypt zone between separate ingress and egress devices. Select services that have already been created from the available list, filter as necessary, and add them to the
Selected Service Chain Order
list.
This service chain list can also be reordered by using the direction arrow buttons.
To use a previously created service chain, select the check box next to the name of the desired service chain type and click
Save & Next
. You can edit any previously created service chain by clicking directly on the name. To create a new service chain, click
Add
.
Only the service chains created as part of this workflow can be deleted.
Security Policy
When configuring the Security Policy screen, you can provide security policy configuration details, including policy conditions, rules, and custom policy details, for your SSL Orchestrator deployment. By default, SSL Orchestrator provides
Pinners_Rule
and
All Traffic
rules.
Pinners_Rule
consists of domain names of some TLS- (SSL-) based services from well-known businesses that support software which may not work well when their connections are intercepted and decrypted by the SSL Orchestrator solution. You can also use the
All Traffic
default rule that allows the interception of all traffic.
Click
Add
to create a new security policy rule. You can specify conditions, match type (match any/match all), and choose the action (reject/allow) for the specified traffic. You can also select a service chain and specify if SSL forward proxy traffic will be intercepted or bypassed.
You can select
Server Certificates Status Check
if you want to add a new per-request policy agent for server certificate status and to allow administrators to select ignore/mask options and generate a blocking page for untrusted and expired server certificates. In addition, you can select
Proxy Connect
if you want to add an upstream explicit proxy to your security rule chaining. You can add multiple proxy devices, or pool members, as necessary.
When selecting a new rule Condition, we recommend you follow these tips:
When you select
Category Lookup (HTTP Connect)
condition, also add the
L7 Protocol Lookup (TCP)
condition.
When you select
L7 Protocol Lookup (UDP)
condition, do not add the
Category Lookup (SNI)
,
Category Lookup (HTTP Connect)
,
SSL Check
, or
URL Match
conditions.
A URLF license is not required to use
Custom Categories
when creating a new URL category.
When you use SSL Orchestrator to provision and deploy an L3 Outbound or L3 Explicit Proxy configuration, and then use BIG-IP Access to configure a custom category, the custom category is supported for the hostname only (with no URLDB or SWG). Therefore, the URL should be configured with the hostname only (for example, http://www.f5.com/). In case of a full URL configuration (http://www.f5.com/services/), the category lookup will result in an uncategorized category (id# 153).
Interception Rule
When configuring the Interception Rule screen, you can set up both outbound and inbound scenarios.
Outbound Topology Scenarios
: Using the SSL Orchestrator default outbound interception rules settings is recommended by F5 and allows you to:
Define your outbound proxy scheme settings to support either
Transparent
or
Explicit
proxy modes.
Simplify your security settings by creating both SSL and Per-Request Policy settings with pre-defined configurations for your outbound rule.
Simplify your ingress network VLAN settings with pre-defined configuration for your outbound rule.
Inbound Topology Scenarios
: You can use the inbound interception rules to create inbound (reverse proxy) listeners. For example, you can setup a gateway where SSL Orchestrator sits in front of your applications (or a separate ADC to do inspections) where a wildcard or SAN certificate is used to decrypt traffic.
Your inbound interception rules can also be optionally (through advanced properties) configured to service individual applications.
Egress Setting
The BIG-IP receives traffic after a connection travels through the specified service chain and directs the traffic to the final destination. When configuring the Egress Setting screen, you can select whether or not you want the system to let all SSL traffic use the default route, or if you want to specify Internet gateways (routers). If you want to override the default routing and choose to use specific gateways, you can define the ratios within the pool of routers to load balance the traffic.
The Egress Setting step is only for L3 topology configurations.
To create egress settings, you must set both SNAT (Secure Network Address Translation) settings and your selected gateway routes for SSL intercept traffic. When managing SNAT settings, you define routable alias IP addresses that the BIG-IP system substitutes for client IP source addresses when making connections to hosts on the external network. You can use an existing SNAT (and thus define a SNAT pool), the SNAT Auto Map functionality, or create new SNAT settings or none at all. Create a BIG-IP SNAT pool to define a pool of distinct host addresses for SNAT to use. A SNAT pool is a pool of translation addresses that you can map to one or more original IP addresses. Translation addresses in a SNAT pool should not be self IP addresses.
For gateway addresses, enter multiple gateways if you have multiple systems and wish to load balance across them. If you do enter multiple addresses, you can also use the ratio value to control the load balancing. For example, if you have two devices, and one handles twice as much traffic as the other, you can set the ratio to 1 on the smaller device, and 2 on the larger one. Create a BIG-IP gateway pool if you add more than one gateway (routers) that specifies the routes of all SSL intercept traffic.
Log Settings
When using the Log Settings screen, you can enable logging for selected facilities at various levels of severity to describe the system messages. Facilities describe the specific element of the system generating the message: Per-Request Policy, FTP, IMAP, POP3, SMTPS, SSL Orchestrator Generic.
The following levels describe the severity of the message and are listed in order of the severity of the messages they handle:
Emergency
: Specifies the emergency system panic messages.
Alert
: Serious errors that require administrator intervention.
Critical
: Critical errors, including hardware and file system failures.
Error
: Non-critical, but possibly very important, error messages.
Warning
: Warning messages that should at least be logged for review.
Notice
: Messages that contain useful information but may be ignored.
Information
: Messages that contain useful information but may be ignored.
Debug
: Messages that are only necessary for troubleshooting.
Generally, higher levels contain all the messages for lower levels. For example, the
Alert
level will generally also report all messages from the
Emergency
level, and the
Debug
level will generally also report all messages for all levels.
Summary
After completing your configuration, or when updating, you can use the Summary screen to review and change configuration settings as necessary for each topology. Select the arrow to review the topology details or select the pencil to edit most field content and re-save.
Preview Merge
The
Preview Merge
option becomes available for previously deployed SSL Orchestrator configurations after a configuration is moved into the
Unprotected Configuration
mode. Once a configuration is unlocked, changes made in any of the following configuration topologies (steps) are available for review and merge configuration options:
Topology
SSL Configuration
Service
Interception Rule
System Settings
See the
Using F5 SSL Orchestrator Preview Merge
section in this guide for more detailed information.

System Settings

High Availability Status (HA-Status)

SSL Orchestrator Dashboard