Applies To:
Show Versions
F5 SSL Orchestrator
- 12.1.0
Summary:
This release note documents the version 12.1.0 release of F5 SSL Orchestrator.
Contents:
- Configuration utility browser support
- iApp template support
- User documentation for this release
- SSL Orchestrator features in 12.1.0
- Known issues
- Contacting F5 Networks
- Legal notices
Configuration utility browser support
The F5 SSL Intercept iApp template acts as the configuration utility for SSL Orchestrator. SSL Orchestrator supports these browsers and versions for use with the configuration utility:
- Microsoft Internet Explorer 11.x - Only 32-bit browsers are supported.
- Mozilla Firefox 27.x
- Google Chrome 32.x
iApp template support
This version of F5 SSL Orchestrator supports version 1.5.6 of the F5 SSL Intercept iApp template.
User documentation for this release
For a comprehensive list of documentation that is relevant to this release, refer to the F5 SSL Orchestrator/ 12.1.0 Documentation page.
SSL Orchestrator features in 12.1.0
F5 SSL Orchestrator
F5 SSL Orchestrator provides an all-in-one appliance solution designed specifically to optimize the SSL infrastructure, provide security devices with visibility of SSL/TLS encrypted traffic, and maximize efficient use of that existing security investment. This solution supports policy-based management and steering of traffic flows to existing security devices, designed to easily integrate into existing architectures, and centralizes the SSL decrypt/encrypt function by delivering the latest SSL encryption technologies across the entire security infrastructure.
Multi-Layered Security
In order to solve specific security challenges, security administrators are accustomed to manually chaining together multiple point products, creating a bare-bones “security stack” consisting of multiple services. A typical stack may include components like Data Leak Prevention (DLP) scanners, Web Application Firewalls (WAF), Intrusion Prevention and Detection Systems (IPS and IDS), Malware Analysis tools, and more. In this model, all user sessions are provided the same level of security, as this “daisy chain” of services is hard-wired.
Dynamic Service Chaining
Dynamic Service Chaining processes specific connections based on context provided by the Classification Engine. These service chains can include four types of services (Layer 2 in-line services, Layer 3 in-line services, receive-only services, and ICAP services) you define, as well as any decrypt zone between separate ingress and egress devices).
Classification Engine
Classification Engine provides a rich set of methods based on context to dynamically determine how best to optimize the flow through the security stack. Context can come from the following:
- Source IP/subnet
- Destination IP/subnet
- IP intelligence category - Subscription
- IP geolocation
- Host and domain name
- URL filtering category - Subscription
- Destination port
- Protocol
Deployment modes
F5 recommends, and has optimized the SSL Orchestrator for deployment in an active-inline mode. This mode supports the broadest set of industry recommended ciphers suites, enables policy-based steering to allow for better utilization of the security services investments deployed at either OSI Layer 2 or Layer 3, and helps reduce administrative costs through efficient steering based on traffic context through selective device load balancing and health monitoring.
Known issues
| ID number | Description |
|---|---|
| 433572 | DTLS does not work with rfcdtls cipher on the B2250 blade. This occurs as a result of hardware acceleration offload on the B2250 blade when using dtls on vCMP. DTLS does not work with rfcdtls cipher on the B2250 blade There is no workaround. |
| 438177 | RSA key/cert pair must be configured as a default in clientssl profile even for only DSA/ECDSA ciphers. This happens if ciphers only contain DSA/ECDSA ciphers. The connection cannot be built up if no RSA key/cert is configured on clientssl profile. The clientssl profile must have RSA key/cert configured. |
| 462754 | The system does not support SSL mirroring with L7 mirroring. When an SSL connection is mirrored, after a few failovers, the connection is reset or the response is delayed for up to several minutes. This occurs when SSL connections are mirrored. The connection is reset or the response is delayed for up to several minutes. The BIG-IP system does not forward the request to the server. In addition, you cannot use L7 features like iRules on mirrored SSL virtual servers. Do not use SSL mirroring with L7 mirroring. SSL mirroring is not supported with L7 mirroring. |
| 464923 | Trying to use a netHSM key without the HSM license causes the SSL handshake to fail with a general error in sign server key exchange. This issue might occur when using netHSM without HSM licensing. The system posts potentially confusing errors similar to the following (with ssl debug logs turned on): -- debug tmm3[28399]: 01260009:7: Connection error: ssl_hs_vfy_sign_srvkeyxchg:8309: sign_srvkeyxchg (80) - info tmm3[28399]: 01260013:6: SSL Handshake failed for TCP 10.10.10.13:47804 -> 10.10.10.23:443 First, license HSM. Then, to determine whether this is the issue related to these messages, you can turn on tmm.verbose. If netHSM is not licensed, you can find the following message at /var/log/tmm: notice No license for external HSM. |
| 474797 | If malformed SSL packets are sent to the BIG-IP system, the following errors can be logged to /var/log/ltm: Device error: cn9 core general. crypto codec cn-crypto-4 queue is stuck. Malformed SSL packets being sent to the BIG-IP system. Error logs in /var/log/ltm. This is a cosmetic issue only, and the errors can be safely ignored. |
| 488314 | Connection stalls and/or connection is reset due to handshake timeout. Mirroring enabled on SSL virtual and failover occurs during SSL handshake, that is, negotiation/renegotiation. SSL connections might stall or be reset on failover. There is no workaround. |
| 488876 | In releases prior to 11.4.0, SSL persistence used very little memory. Beginning in version 11.4.0 and continuing, the amount of memory has increased. This occurs when SSL persistence is enabled. This results in less memory being available for other flows, and might eventually result in TMM being out of memory. There is no workaround. |
| 489572 | Sync fails if you create/import an SSL key and delete it before triggering manual sync, and ltm logs contain messages similar to the following: Standby: -- err mcpd[7339]: 01070712:3: Caught configuration exception (0), Failed to sync files.. -- err mcpd[7339]: 01071488:3: Remote transaction for device group /Common/test to commit id 42 6079477704784246664 /Common/test failed with error 01070712:3: Caught configuration exception (0), Failed to sync files... Active: -- err mcpd[6319]: 0107134a:3: File object by name (/Common/test.key) is missing. This occurs when BIG-IP systems are configured for manual-sync high availability, and one or more keys are created and deleted before performing manual sync from Active to Standby. Sync fails. If you create a key, make sure to sync before deleting it. |
| 499750 | Sometimes, the BIG-IP system sends the _SHA256 cipher in the ClientHello message of TLS1.0. This occurs when using the _SHA256 cipher in clientssl and serverssl profiles. Depends on the peer implementation. Sometimes the Peer SSL responds with an Alert message and refuses to establish a connection. There is no workaround. |
| 511664 | The fipskey.nethsm utility does not support or enforce RFC 3280 with regards to field length Upper/Lower Bounds. |
| 562370 | SSL traffic may be stalled if there is a mismatch in mirror setting on the SSL virtual server between the active and the standby unit. SSL virtual server with mirroring enabled on the active unit and disabled on the standby unit. Connections on the active unit may be stalled up to "Handshake timeout" seconds. Configure both units to have the same mirror setting on the virtual server. |
| 570277 | SafeNet client not able to establish session to all HSMs on all blades. |
| 574250 | Inserting a new blade in a chassis that already has HSM installed requires user to re-enter the HSM partition password. VIPRION chassis. Inserting a new blade. Chassis already has HSM installed. User is prompted to enter HSM partition password for installation. |
| 574259 | The BIG-IP system does not automatically run the synchronization process when a new blade is inserted to a chassis. Inserting a new blade into a VIPRION chassis. New blade must be synced manually. There is no workaround. |
| 578076 | See sol23196136 at https://support.f5.com/kb/en-us/solutions/public/k/23/sol23196136.html. |
| 581660 | The netHSM connection may fail with a message "cannot locate key". This only affects Thales users. SafeNet users are not affected by this issue. This may happen after restarting pkcs11d without starting tmm immediately after. SSL handshake failure with a message similar to the following: SSL Handshake failed for TCP 10.10.0.1:59513 -> 10.10.1.150:20001. There is no workaround. |
| 581877 | Internal code review revealed that in rare scenarios, the handling of TLS padding in CBC decryption code could be hardened. Undisclosed. The possibility to exploit padding timing channel is reduced. For Thales, always restart tmm after restarting pkcs11d. To do so, run the following commands: bigstart restart pkcs11d bigstart restart tmm |
| 582465 | After the SafeNet Hardware Security Module (HSM) is restarted, users cannot generate a new key. The BIG-IP system uses the SafeNet HSM. HSM service is not usable even after restarting pkcs11d. Users must re-authenticate. To generate a new key, after HSM finishes starting up, run the following commands: #/shared/safenet/toolkit/sautil -v -s 1 -i 10:11 -c #/shared/safenet/toolkit/sautil -v -s 1 -i 10:11 -o -p <hsm_partition_password> Or, you can reinstall SafeNet client. |
| 592647 | Thales client install does not work with existing RFS with non-root access. There is no workaround. |
| 597099 | SSL forward proxy appears to be unable to handle an SSL handshake inside an explicit proxy 'CONNECT' request. This appears to be the case if the explicit proxy trails the SSL Forward Proxy, or is within the inspection zone. There is no workaround. |
| 602568 | Changes were made to DEFAULT in LTM SSL profiles in order to improve SSL ciphersuite group selection. When DEFAULT" group is used, the following changes have been made. Original Default Ciphersuite Group: RSA+DH RSA RSA+ECDH Original Default + ECDHE_ECDSA RSA+DH RSA RSA+ECDH ECDSA+ECDH Update to: DEFAULT will contain ciphersuites in the following categories in this order in the BIG-IP's view: RSA+ECDH RSA ECDSA+ECDH RSA+DH In addition, each category will be sorted by speed with AES-128-equivalent as the minimum strength (commonly referred to as "128-bit security strength"). Do not use DEFAULT ciphergroup and specify customer ciphergroup. |
| 604273 | SMTPS profile connections_current stat does not reflect actual connection count. |
| 604714 | Some sites need the SSL/TLS version (both in the Record layer and Handshake Protocol) in the 2nd ClientHello after receiving the HelloRequest to be exactly the same as the SSL/TLS version of the 1st ClientHello; that is: *********************** 1st ClientHello record layer version == 2nd ClientHello record layer version; 1st ClientHello Handshake Protocol version == 2nd ClientHello Handshake Protocol version. *********************** The BIG-IP system default behavior is to set the SSL/TLS ClientHello version to be the negotiated version in only the first round ServerHello. This occurs when using virtual servers configured with one or more SSL profiles The SSL renegotiation after receiving the HelloRequest will fail. Manually setting the ciphers in the ServerSSL to TLS1.0 can solve the issue. |
| 604718 | SSL::sessionid output is not consistent with the sessionid field of ServerHello message. This is mostly cosmetic, but if an iRule depends upon the outcome, the result can be unexpected. This occurs when using an iRule to inspect the session ID on server-side SSL. The values do not match. SSL::sessionid outputs the wrong sessionid. Manually setting the ciphers in the ServerSSL to TLS1.0 can solve the issue. |
| 605682 | If forward proxy is enabled, and a required forged certificate is not in the cache, the connection might not complete. Forward proxy is enabled, and a required forged certificate is not in the cache. Degraded service due to connections not completing. There is no workaround. |
| 608627 | TMM crash and core dump when processing SSL protocol alert. During SSL handshake, if the server sends protocol Alert to the BIG-IP system, TMM might crash. Traffic disrupted while tmm restarts. Do not use DEFAULT ciphergroup and specify customer ciphergroup. |
| 609628 | When a client performs an abbreviated handshake by reusing the session from a previously established full handshake, the SSL forward proxy does not raise the CLIENTSSL_SERVERHELLO_SEND event. This occurs when the following conditions are met: -- SSL forward proxy configured -- Session cache is enabled. iRule commands inside of the CLIENTSSL_SERVERHELLO_SEND are only executed for full handshakes, but not for abbreviated handshakes; thus any logic that's applied per SSL connection should not run inside of CLIENTSSL_SERVERHELLO_SEND event since it is not reliably raised under all types of handshakes. To make sure that the CLIENTSSL_SERVERHELLO_SEND event is reliably raised, disable session cache in the client SSL profile. |
| 609588 | Using certain iRules on virtual servers with OCSP Stapling enabled on the Client SSL profile might cause OCSP requests to be reissued, resulting in a memory leak. You may notice warning messages similar to the following in /var/log/ltm: warning tmm[11300]: 011e0003:4: Aggressive mode sweeper: /Common/default-eviction-policy (0) (global memory) 115 Connections killed. This occurs when the following conditions are met: -- Virtual server with OCSP Stabling enabled. -- iRule attached to the virtual server that uses SSL::renegotiate. TMM memory used increases gradually, eventually the aggressive mode sweeper is activated. |
| 610163 | A TLS client using the initial release of SSL Intercept with Service Chaining v1.5.0 will execute a full TLS handshake for every intercepted TLS connection, as TLS Session resumption (abbreviated handshake) is not enabled in this release. Each TLS connection that is intercepted (decrypted) by the SSL Intercept v1.5.0 solution initial release will utilize a full TLS handshake. This constraint does not apply to TLS connections that are not intercepted ("bypass" mode).This constraint does not impact TLS security. However, performance of a client that makes multiple connections to the same server in a short timeframe may be reduced. Not all clients attempt session resumption so an effect may or may not be noticed. |
| 610234 | Configuring the SSL Intercept with Service Chaining v1.5.0 solution with multiple services may produce slow response or errors. The error messages in the BIG-IP logs may reference "ajp_read_header". Add more Java heap memory to Tomcat as explained in SOL9719. |
| 610475 | When a non-public external IPv6 route is added inside the SSL Intercept with Service Chaining v1.5.0 iApp, it may not be correctly configured in the system. Add the route using the BIG-IP management user interface or tmsh. |
Contacting F5 Networks
| Phone: | (206) 272-6888 |
| Fax: | (206) 272-6802 |
| Web: | http://support.f5.com |
| Email: | support@f5.com |
For additional information, please visit http://www.f5.com.
How to Contact F5 Support or the Anti-Fraud SOC
- By phone in the U.S. (accessible 24x7): 888-88askf5 (888-882-7535).
- International contact numbers: http://www.f5.com/training-support/customer-support/contact/.
- The Support Coordinator can contact the SOC as needed.
You can manage cases online at F5 WebSupport (registration required). To register email CSP@F5.com with your F5 hardware serial numbers and contact information.
You can contact the Anti-Fraud SOC as follows:
- By phone in the U.S. (accessible 24x7): 866-329-4253 (Option #3 for Anti-Fraud)
- International contact numbers: https://f5.com/products/platforms/silverline/f5-silverline-ddos-protection
Additional resources
You can find additional support resources and technical documentation through a variety of sources.
- The F5 Networks Technical Support web site: http://www.f5.com/support/
- The AskF5 web site: http://support.f5.com/kb/en-us.html
- The F5 DevCentral web site: http://devcentral.f5.com/
- AskF5 TechNews
F5 Networks Technical Support
Free self-service tools give you 24x7 access to a wealth of knowledge and technical support. Whether it is providing quick answers to questions, training your staff, or handling entire implementations from design to deployment, F5 services teams are ready to ensure that you get the most from your F5 technology.
AskF5
AskF5 is your storehouse for thousands of solutions to help you manage your F5 products more effectively. Whether you want to search the knowledge base periodically to research a solution, or you need the most recent news about your F5 products, AskF5 is your source.
F5 DevCentral
The F5 DevCentral community helps you get more from F5 products and technologies. You can connect with user groups, learn about the latest F5 tools, and discuss F5 products and technology.
AskF5 TechNews
- Weekly HTML TechNews
- The weekly TechNews HTML email includes timely information about known issues, product releases, hotfix releases, updated and new solutions, and new feature notices. To subscribe, click TechNews Subscription, complete the required fields, and click the Subscribe button. You will receive a confirmation. Unsubscribe at any time by clicking the Unsubscribe link at the bottom of the TechNews email.
- Periodic plain text TechNews
- F5 Networks sends a timely TechNews email any time a product or hotfix is released. (This information is always included in the next weekly HTML TechNews email.) To subscribe, send a blank email to technews-subscribe@lists.f5.com from the email address you are using to subscribe. Unsubscribe by sending a blank email to technews-unsubscribe@lists.f5.com.
