Protocol negotiation usually happens silently and almost always lands on the latest version both sides support. forceTlsVersionAction gives you a deterministic way to override that decision so you can verify legacy support, reproduce a TLS specific bug, or confirm a server has retired an obsolete protocol.
Use forceTlsVersionAction when you want to control exactly which TLS protocol Fluxzy negotiates with the upstream server. The action makes it easy to reproduce protocol specific behaviour without changing OS level settings or client code.
Typical situations include:
The action runs on the requestHeaderReceivedFromClient scope. Valid values for sslProtocols include Tls, Tls11, Tls12, Tls13, plus legacy entries Ssl3 and Ssl2.
Helps you reproduce bugs on a client that has migrated to TLS 1.3 by default.
rules:
- filter:
typeKind: HostFilter
pattern: api.internal.example.com
actions:
- typeKind: ForceTlsVersionAction
sslProtocols: Tls12
A failed handshake confirms that the server has correctly removed support.
rules:
- filter:
typeKind: HostFilter
pattern: legacy.example.com
actions:
- typeKind: ForceTlsVersionAction
sslProtocols: Tls
Combined with HTTP/2, this matches the baseline of a current generation browser.
rules:
- filter:
typeKind: HostFilter
pattern: payments.example.com
actions:
- typeKind: ForceTlsVersionAction
sslProtocols: Tls13
- typeKind: ForceHttp2Action
Force the usage of a specific TLS version. Values can be chosen among : Tls, Tls11, Tls12, Tls13, Ssl3, Ssl2.
Forcing the usage of a specific TLS version can break the exchange if the remote does not support the requested protocol.
Evaluation scope defines the timing where this filter will be applied.
requestHeaderReceivedFromClient This scope occurs the moment fluxzy parsed the request header receiveid from client
forceTlsVersionAction
The following table describes the customizable properties available for this action:
| Property | Type | Description | DefaultValue |
|---|---|---|---|
| sslProtocols | none | ssl2 | ssl3 | tls | default | tls11 | tls12 | tls13 | none |
The following examples apply this action to any exchanges
Accept only TLS 1.1 connections.
rules:
- filter:
typeKind: AnyFilter
actions:
- typeKind: ForceTlsVersionAction
sslProtocols: Tls11
View definition of ForceTlsVersionAction for .NET integration.
The following actions are related to this action:
The handshake fails and the exchange surfaces a TLS error. That is often exactly what you want when probing a server for protocol support.
No. It only forces the protocol version. Cipher selection still follows the operating system or runtime defaults.
Yes. Add skipRemoteCertificateValidationAction in the same rule if you also want to bypass certificate checks while testing.
Yes. These protocols are obsolete and considered unsafe. They are available in the action only so you can probe servers that should reject them.