If you have an LTM® SSL forward proxy configuration, you can add a per-request policy to it. Every time a client makes a URL request, the per-request policy runs. The policy can contain any available per-request policy action item, including those for URL and application categorization and filtering.
Complete these tasks before you start:
Before you begin, gather the IP addresses of the nameservers that you want to associate with a forward zone.
When you create an OAuth Server, creating a DNS Resolver with a forward zone named . (period) is mandatory.
To add per-request processing to an LTM® SSL forward proxy configuration, associate the access profile, custom HTTP profile, and per-request policy with the virtual server.
SSL bypass decision based on group membership and URL category
|1||SSL traffic exits on the HTTPS branch of Protocol Lookup.|
|2||A lookup type item, such as LocalDB Group Lookup, identifies users in a group, Directors.|
|3||With SSL Bypass Set, any SSL request on the Directors branch is not intercepted or inspected.|
|4||Category Lookup processes HTTPS traffic when configured to use SNI or Subject.CN input.
Note: Finance or Govt is a standard URL category that SWG maintains on a system with an SWG subscription. User-defined URL categories can provide an alternative on systems without an SWG subscription.
|5||For users in a group other than Directors, bypass only requests that contain private information (determined through Category Lookup).|
|6||SSL traffic processing is complete. Now is the time to start processing HTTP data with actions that inspect the SSL payload. Using data provided by Category Lookup, URL Filter Assign item determines whether to allow or block traffic.|
(For this example to be valid, both the server and client SSL profiles on the virtual server must enable SSL forward proxy and SSL forward proxy bypass; the client SSL profile must set the default bypass action to Intercept.)
With the BIG-IP® system's SSL forward proxy functionality, you can encrypt all traffic between a client and the BIG-IP system, by using one certificate, and to encrypt all traffic between the BIG-IP system and the server, by using a different certificate.
A client establishes a three-way handshake and SSL connection with the wildcard IP address of the BIG-IP system virtual server. The BIG-IP system then establishes a three-way handshake and SSL connection with the server, and receives and validates a server certificate (while maintaining the separate connection with the client). The BIG-IP system uses the server certificate to create a second unique server certificate to send to the client. The client receives the second server certificate from the BIG-IP system, but recognizes the certificate as originating directly from the server.
A virtual server configured with Client and Server SSL profiles for SSL forward proxy functionality
To implement SSL forward proxy client-to-server authentication, as well as application data manipulation, you perform a few basic configuration tasks. Note that you must create both a Client SSL and a Server SSL profile, and enable the SSL Forward Proxy feature in both profiles.
You perform this task to create a Client SSL forward proxy profile that makes it possible for client and server authentication while still allowing the BIG-IP® system to perform data optimization, such as decryption and encryption. This profile applies to client-side SSL forward proxy traffic only.
After you complete the tasks in this implementation, the BIG-IP® system ensures that the client system and server system can authenticate each other independently. After client and server authentication, the BIG-IP system can intelligently decrypt and manipulate the application data according to the configuration settings in the profiles assigned to the virtual server.