Is your feature request related to a problem? Please describe.
Our organization currently uses LTM Policy objects to do encryption-strength checking at connection time. We have an existing policy that checks the TLS version and cipher bits, then if the encryption is not sufficient, responds with an HTTP redirect to a sorry-server page. We are in the process of converting our configuration to AS3 and have found that we cannot currently use AS3 to build such a policy as it lacks the schema/feature support for Client SSL conditions.
Our conditions currently look like the following on the BIG-IP GUI:
Describe the solution you'd like
Create a new Policy_Condition type (suggested name Policy_Condition_Client_SSL) that allows configuring the above Client SSL conditions. This class would have the following properties:
Name (Type)
Default
Values
Description
cipher _(Policy_CompareString)
Match against the cipher selected by the client SSL handshake
cipherBits _(Policy_CompareNumber)
Match against the bit strength of the cipher selected by the client SSL handshake
When to evaluate this condition in the request-response cycle
protocol _(Policy_CompareString)
Match against the protocol selected by the client SSL handshake
When conditions of this new type are supplied in the conditions array property of an Endpoint_Policy_Rule object, create the relevant conditions on the LTM Policy that is configured on the BIG-IP by the associated Endpoint_Policy object.
Describe alternatives you've considered
For the time being, we are using alternative methods to provision the Policy on the device, but those methods are not long-term feasible as their implementations (iControlREST and/or tmsh commands) are not aligned with BIG-IP v20.
Strictly using cipher groups on the Client SSL profile are failing the handshake is not currently an option, as it is a business and customer requirement at this time to provide the graceful degradation via the sorry-server redirect.
Additionally, we are aware that we could implement this same capability with an iRule (and have done so previously for a limited number of configurations) but LTM Policy remains the preferred option for performance reasons; migrating all of our existing configurations from LTM Policy to an iRule is a nontrivial action for us.
Is your feature request related to a problem? Please describe.
Our organization currently uses LTM Policy objects to do encryption-strength checking at connection time. We have an existing policy that checks the TLS version and cipher bits, then if the encryption is not sufficient, responds with an HTTP redirect to a sorry-server page. We are in the process of converting our configuration to AS3 and have found that we cannot currently use AS3 to build such a policy as it lacks the schema/feature support for Client SSL conditions.
Our conditions currently look like the following on the BIG-IP GUI:
Describe the solution you'd like
Create a new
Policy_Condition
type (suggested namePolicy_Condition_Client_SSL
) that allows configuring the above Client SSL conditions. This class would have the following properties:When conditions of this new type are supplied in the
conditions
array property of anEndpoint_Policy_Rule
object, create the relevant conditions on the LTM Policy that is configured on the BIG-IP by the associatedEndpoint_Policy
object.Describe alternatives you've considered
For the time being, we are using alternative methods to provision the Policy on the device, but those methods are not long-term feasible as their implementations (iControlREST and/or tmsh commands) are not aligned with BIG-IP v20.
Strictly using cipher groups on the Client SSL profile are failing the handshake is not currently an option, as it is a business and customer requirement at this time to provide the graceful degradation via the sorry-server redirect.
Additionally, we are aware that we could implement this same capability with an iRule (and have done so previously for a limited number of configurations) but LTM Policy remains the preferred option for performance reasons; migrating all of our existing configurations from LTM Policy to an iRule is a nontrivial action for us.