Original Publication Date: 09/10/2018
This release note documents the version 12.1.0 release of F5 SSL Orchestrator.
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:
This version of F5 SSL Orchestrator supports version 1.5.6 of the F5 SSL Intercept iApp template.
For a comprehensive list of documentation that is relevant to this release, refer to the F5 SSL Orchestrator/ 12.1.0 Documentation page.
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.
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 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 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:
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.
|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: 01260009:7: Connection error: ssl_hs_vfy_sign_srvkeyxchg:8309: sign_srvkeyxchg (80) - info tmm3: 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: 01070712:3: Caught configuration exception (0), Failed to sync files.. -- err mcpd: 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: 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: 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.|
For additional information, please visit http://www.f5.com.
You can contact the Anti-Fraud SOC as follows:
You can find additional support resources and technical documentation through a variety of sources.
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 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.
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.