[F5 SSLO] LAB 1 – Transparent Forward Proxy Configuration

• TCP: This option creates a single TCP wildcard interception rule for the L3 Inbound, L3 Outbound, and L3 Explicit Proxy topologies.
• UDP: This option creates a single UDP wildcard interception rule for L3 Inbound and L3 Outbound topologies.
• Other: This option creates a single any protocol wildcard interception rule for L3 Inbound and L3 Outbound topologies, typically used for non-TCP/UDP traffic flows.
• Any: This option creates the TCP, UDP and non-TCP/UDP interception rules for outbound traffic flows.

• L3 Explicit Proxy: This is the traditional explicit forward proxy.
• L3 Outbound: This is the traditional transparent forward proxy. An L3 outbound topology is effectively a “routed hop” configuration, where the SSLO topology listener becomes a routed path on the way to external (ie. Internet) resources.
• L3 Inbound: This is a reverse proxy configuration. Like the L3 outbound, L3 inbound is typically a routed hop configuration for traffic directed inbound. It can also behave as a traditional loadbalanced application.
• L2 Inbound: The layer 2 topology options insert SSLO as a bump-in-the-wire in an existing routed path, where SSLO presents no IP addresses on its outer edges. The L2 Inbound topology provides a transparent path for inbound traffic flows.
• L2 Outbound: The layer 2 topology options insert SSLO as a bump-in-the-wire in an existing routed path, where SSLO presents no IP addresses on its outer edges. The L2 Outbound topology provides a transparent path for outbound traffic flows.
• Existing Application: This topology is designed to work with existing LTM applications. Whereas the L3 Inbound topology provides an inbound gateway function for SSLO, Existing Application works with LTM virtual servers that already perform their own SSL handling and client-server traffic management. The Existing Application workflow proceeds directly to service creation and security policy definition, then exits with an SSLO-type access policy and per-request policy that can easily be consumed by an LTM virtual server.

Note:
(*) It is important to distinguish SSLO’s L2 topology from those of other traditional L2 SSL visibility vendors. 
(*) “True” L2 solutions like Blue Coat’s SSLVA limit the types of devices that can be inserted into the inspection zone to L2 and below, and devices must be directly connected to the appliance.
(*) SSLO’s L2 topology only exists at the outer edges. Inside the inspection zone, full-proxy routing is still happening, so L3 and HTTP services can still function normally.

• SNI Server Name (FQDN):
  • Optionally specify the fully qualified DNS hostname of the server which is used in Server Name Indication (SNI) communications.
  • If you attach multiple SSL profiles, one of them must be the default SNI.
  • Select the Default SNI checkbox to indicate that the system uses this profile as the default SSL profile when there is no match to the server name, or when the client provides no SNI extension support.
  • Only one default SNI is allowed.
• Certificate Key Chain:
  • Represents the certificate and private key used as the “template” for forged server certificates.
  • While re-issuing server certificates on-the-fly is generally easy, private key creation tends to be a CPU-intensive operation.
  • For that reason, the underlying SSL Forward Proxy engine forges server certificates from a single defined private key.
  • This setting provides the opportunity to apply custom template private key, and optionally store that key in a FIPS-certified HSM for additional protection.
  • The built-in “default” certificate and private key uses 2K RSA and is generated from scratch when the BIG-IP system is installed.
• CA Certificate Key Chain:
  • An SSL forward proxy must re-sign, or “forge” remote server certificate to local clients using a local CA certificate, and local clients must trust this local CA.
  • This setting defines the local CA certificate and private key used to perform the forging operation.
  • SSL Settings minimally require RSA-based template and CA certificates but can also support Elliptic Curve (ECDSA) certificates.
  • In this case, SSLO would forge an EC certificate to the client if the TLS handshake negotiated an ECDHE_ECDSA cipher.
  • To enable EC forging support, add both an EC template certificate and key, and EC CA certificate and key.
• ALPN:
  • The Proxy ALPN checkbox option specifies the ALPN hello extension to be proxied to the server by SSL Forward Proxy.
  • This allows the client to negotiate with server for protocols like HTTP/2.
  • If the Proxy ALPN checkbox is not selected, then HTTP1.1 will be utilised by default.

• Bypass on Handshake Alert:
  • This setting allows the underlying SSL Forward Proxy process to bypass SSL decryption if an SSL handshake error is detected on the server side.
  • It is recommended to leave this disabled.
• Bypass on Client Certificate Failure:
  • This setting allows the underlying SSL Forward Proxy process to bypass SSL decryption if it detects a Certificate request message from the server, as in when a server requires mutual certificate authentication.
  • It is recommended to leave this disabled.
• Trusted Certificate Authority
  • Browser vendors routinely update the CA certificate stores in their products to keep up with industry security trends, and to account for new and revoked CAs.
  • In the SSL forward proxy use case, however, the SSL visibility product now performs all server-side certificate validation, in lieu of the client browser, and should therefore do its best to maintain the same industry security trends.
  • BIG-IP ships with a CA certificate bundle that maintains a list of CA certificates common to the browser vendors.
  • However, a more comprehensive bundle can be obtained from the F5 Downloads site.
• Expire Certificate Response
  • SSLO performs validation on remote server certificates and can control what happens if it receives an expired server certificate.
  • The options are drop, which simply drops the traffic, and ignore, which mirrors an expired forged certificate to the client.
  • The default and recommended behaviour for forward proxy is to drop traffic on an expired certificate.
• Untrusted Certificate Authority
  • SSLO performs validation on remote server certificates and can control what happens if it receives an untrusted server certificate, based on the Trusted Certificate Authority bundle.
  • The options are drop, which simply drops the traffic, and ignore, which allows the traffic and forges a good certificate to the client.
  • The default and recommended behavior for forward proxy is to drop traffic on an untrusted certificate.
• OCSP Certificate Validator
  • This setting selects an existing or can create a new OCSP profile for server-side Online Certificate Status Protocol (OCSP) and OCSP stapling.
  • With this enabled, if a client issues a Status Request message in its Client Hello message (an indication that it supports OCSP stapling), SSLO will issue a corresponding Status Request message in its server-side TLS handshake.
  • SSLO will then forge the returned OCSP stapling response back to the client.
  • If the server does not respond with a staple but contains an Authority Info Access (AIA) field that points to an OCSP responder URL, SSLO will perform a separate OCSP request.
  • The returned status is then mirrored in the stapled client-side TLS handshake.
• CRL Certificate Validator
  • This setting selects an existing or can create a new CRL profile for server-side Certificate Revocation List (CRL) validation.
  • With this enabled, SSLO attempts to match server certificates to locally cached CRLs.

Note:
The above two Bypass options can create a security vulnerability.
(*) If a colluding client and server can force an SSL handshake error,
(*) or force client certificate authentication, they can effectively bypass SSL inspection.
(*) It is recommended that these settings be left disabled.

• Service Action Down: SSLO also natively monitors the load balanced pool of security devices, and if all pool members fail, can actively bypass this service (Ignore), or stop all traffic (Reset, Drop). For this lab, leave it set to Ignore.
• Internal IP Offset: This setting specifies an internal IP Offset to generate the Internal IPv4 and IPv6 addresses. For High Availability (HA) configurations, the Internal IP Offset index numbers must be the same on all HA devices (Active and Standby). For scaled standalone configurations where non-HA standalone SSLO appliances are scaled behind a separate load balancer, the Internal IP Offset index numbers must be different across all devices.
• Enable Port Remap: This setting allows SSLO to remap the port of HTTPS traffic flowing across this service. This is advantageous when a security service defines port 443 traffic as encrypted HTTPS and natively ignores it. By remapping HTTPS traffic to, say, port 8080, the security service will inspect the traffic.
• iRules: SSLO now allows for the insertion of additional iRule logic at different points. An iRule defined at the service only affects traffic flowing across this service. It is important to understand, however, that these iRules must not be used to control traffic flow (ex. pools, nodes, virtual servers, etc.), but rather should be used to view/modify application layer protocol traffic. For example, an iRule assigned here could be used to view and modify HTTP traffic flowing to/from the service.

Note:
N/A

• Auto Manage Addresses: When enabled the Auto Manage Addresses setting provides a set of unique, non-overlapping, non-routable IP addresses to be used by the security service. If disabled, the To and From IP addresses must be configured manually. It is recommended to leave this option enabled (checked).
• To Service: With the Auto Manage Addresses option enabled, this IP address will be pre-defined, therefore the inbound side of the service must match this IP subnet. With the Auto Manage Addresses option disabled, the IP address must be defined manually. For this lab, leave the 198.19.64.7/25 address intact.
• From Service: With the Auto Manage Addresses option enabled, this IP address will be pre-defined, therefore the outbound side of the service must match this IP subnet. With the Auto Manage Addresses option disabled, the IP address must be defined manually. For this lab, leave the 198.19.64.245/25 address intact.
• Manage SNAT Settings: SSLO now defines an option to enable SNAT (source NAT) across an inline layer 3/HTTP service. The primary use case for this is horizontal SSLO scaling, where independent SSLO devices are scaled behind a separate load balancer but share the same inline layer 3/HTTP services. As these devices must route back to SSLO, there are now multiple SSLO devices to route back to. SNAT allows the layer 3/HTTP device to know which SSLO sent the packets for proper routing. SSLO scaling also requires that the Auto Manage option be disabled, to provide separate address spaces on each SSLO. For this, leave it set to None.

Note:
In environments where SSLO is introduced to existing security devices, it is a natural tendency to not want to have to move these devices.
(*) And while SSLO certainly allows it, by not moving the security devices into SSLO-protected enclaves,
(*) Customers run the risk of exposing sensitive decrypted traffic, unintentionally, to other devices that may be connected to these existing networks. 
(*) It is therefore highly recommended, and a security best practice, to remove SSLO-integrated security devices from existing networks and place them entirely within the isolated enclave created and maintained by SSLO.

• Authentication Offload: When an Access authentication profile is attached to an explicit forward proxy topology, this option will present the authenticated username value to the service as an X-Authenticated-User HTTP header.

Note:
N/A

• ICAP Headers: Select either Default or Custom to specify additional ICAP headers. To add custom headers, select Custom, otherwise leave as Default.
• OneConnect: The F5 OneConnect profile improves performance by reusing TCP connections to ICAP servers to process multiple transactions. If the ICAP servers do not support multiple ICAP transactions per TCP connection, do not enable this option.
• Request Modification URI Path: This is the RFC 3507-defined URI request path to the ICAP service. Each ICAP security vendor will differ with respect to request and response URIs, and preview length, so it is important to review the vendor’s documentation.
• Response Modification URI Path: This is the RFC 3507-defined URI response path to the ICAP service. Each ICAP security vendor will differ with respect to request and response URIs, and preview length, so it is important to review the vendor’s documentation.
• Preview Max Length (bytes): This defines the maximum length of the ICAP preview. Each ICAP security vendor will differ with respect to request and response URIs, and preview length, so it is important to review the vendor’s documentation. A zero-length preview length implies that data will be streamed to the ICAP service, similar to an HTTP 100/Expect process, while any positive integer preview length defines the amount of data (in bytes) that are transmitted first, before streaming the remaining content. The ICAP service in this lab environment does not support a complete stream, so requires a modest amount of initial preview.
• HTTP Version: This defines whether SSLO sends HTTP/1.1 or HTTP/1.0 requests to the ICAP service.
• ICAP Policy: An ICAP policy is a pre-defined LTM CPM policy that can be configured to control access to the ICAP service based on attributes of the HTTP request or response. ICAP processing is enabled by default, so an ICAP CPM policy can be used to disable the request and/or response ADAPT profiles.

Note:
N/A

• Mac Address: For a tap service that is not directly connected to the F5, enter the device’s MAC address. For a tap service that is directly connected to the F5, the MAC address does not matter and can be arbitrarily defined.
• VLAN: This defines the interface connecting the F5 to the TAP service.

Note:
N/A