SSL Version

What Is the SSL Version Condition?

SSL Version is a condition type used to make traffic routing and manipulation decisions by evaluating the TLS/SSL protocol version used in the connection between the client and TR7.

During the TLS handshake, the client and the server agree on a common protocol version.

TLS Handshake

Client Hello → "I support TLSv1.3, TLSv1.2, TLSv1.1"

↓

Server Hello → TLSv1.3 will be used

Selected Version

This condition makes it possible to apply security policies by using the protocol version information determined after the TLS handshake.

TIP

This condition can be used only in cases where SSL Offloading/Termination is performed by TR7 on the related vService.

The Importance of the SSL Version Condition

The TLS/SSL protocol version directly affects the security level of the connection. Old versions have known security vulnerabilities.

With the SSL Version condition:

• Insecure protocol versions (SSLv2, SSLv3, TLSv1) can be detected and blocked,
• PCI DSS and security compliance requirements can be met,
• Warning pages can be shown to old clients,
• Protocol version distribution statistics can be collected,
• Priority can be given to connections using modern TLS.

TLS/SSL Version Security Status:

Version	Status	Description
TLSv1.3	✅ Secure	Modern and recommended version
TLSv1.2	✅ Secure	In widespread use, secure
TLSv1.1	⚠️ Deprecated	Deprecated in 2021, should not be used
TLSv1	❌ Insecure	Known vulnerabilities (BEAST, POODLE)
SSLv3	❌ Insecure	POODLE vulnerability, should not be used
SSLv2	❌ Insecure	Many critical vulnerabilities, must definitely not be used

Supported vService Types

HTTP

L7 TCP

Network

How to Add?

A new SSL Version Condition can be added through the TR7 web management interface by following the steps below:

1. The Configuration Menu is opened by clicking the TR7 logo at the bottom left.
2. The Load Balancer → Conditions → Add steps are followed.
3. SSL version is selected as Criteria.
4. The related configurations of the condition are made.
5. The condition is added by clicking the Add button.

SSL Version Condition Add Form

SSL Version Condition Add Form

INFO

Condition Name

An optional name can be entered for the condition to be created.

This field is especially important in the following scenarios:

• When many conditions are defined under the same vService,
• When conditions with similar criteria need to be distinguished,
• When it is necessary to quickly understand which business rule the condition represents.

When this field is left empty, TR7 analyzes the content of the related condition and creates an automatic, descriptive name in the Condition Description field. This generated description is used as the name in condition lists.

INFO

Criteria Required

The field that determines the type of the condition; SSL version is selected from the searchable dropdown list. This selection determines the fields displayed in the form. The criterion cannot be changed after the condition is saved: if a different criterion is needed, a new condition is defined. For all criteria in the list and their scopes, the criteria catalog on the Conditions page can be referred to.

INFO

SSL Protocol Required

The TLS/SSL protocol version to be detected is selected from the list. The field is single-select and the matching is full text: if more than one version is to be checked, a separate condition is defined for each version. Free text/pattern cannot be entered.

Available Protocol Versions:

Version	Security	Usage Recommendation
TLSv1.3	✅ High	Recommended, modern clients
TLSv1.2	✅ Good	Widespread, secure
TLSv1.1	⚠️ Deprecated	Should be blocked
TLSv1	❌ Insecure	Should be blocked
SSLv3	❌ Insecure	Must definitely be blocked
SSLv2	❌ Insecure	Must definitely be blocked

WARNING

TLSv1.3 is not supported by some old clients. For compatibility requirements, TLSv1.2 can be accepted as the minimum.

WARNING

The TLS security profile of the vService already applies the minimum allowed version at the handshake stage: a connection cannot be established at all with the versions rejected by the profile, and this condition is not reached for evaluation. The condition is used only to distinguish between the versions allowed by the profile (e.g. marking these clients while TLSv1.2 is allowed).

TIP

The condition produces a value only in vServices where SSL termination is performed; in a vService without SSL it silently does not match (for the "is there SSL" distinction, the ready-made If SSL is terminated condition can be used). The protocol version used can be printed in actions with the TLS Protocol Info in Incoming Connection (e.g., TLSv1) smart variable.

INFO

Condition Description

It is created automatically by TR7 in line with the entered criteria and values.

This description:

• which value the condition applies to,
• which criterion it works on,
• the quick understanding of the condition on listing screens

is produced dynamically by the system so as to provide these.

INFO

Form Buttons

Add

The condition adding process is completed by clicking the Add button.

Add & Repeat

With the Add & Repeat button, the condition adding process is completed, and another new condition can be added with different configurations without leaving the related window.

Condition Added

Operational Usage Recommendations

• Old Protocols Should Be Blocked. Connections using SSLv2, SSLv3 and TLSv1 should be detected and blocked, or a warning should be shown.
• PCI DSS Compliance. For the PCI DSS 3.2+ requirements, TLSv1.1 and below should be blocked. A minimum of TLSv1.2 should be made mandatory.
• Gradual Migration. A warning should first be shown to clients using an old protocol, and after a certain period they should be blocked completely.
• It Should Be Used for Monitoring. By monitoring which versions are used, the ratio of old clients should be tracked.

Common Usage Scenarios in Live Environments

The examples below show how the related condition is applied in the most frequently encountered use cases in real systems. These scenarios are based on practices that are widely preferred in live environments and rest on experience gained in the field.

Scenario 1: Blocking SSLv3 and TLSv1.0 (POODLE Protection)

Purpose: To increase security by detecting and blocking the old protocol versions (SSLv3, TLSv1) that have the POODLE and BEAST security vulnerabilities.

Configuration: SSL Protocol → TLSv1 (a separate condition is defined for SSLv3; the two are combined with OR in the rule). This scenario is meaningful if the TLS profile of the vService allows these versions.

Action Recommendations:

• ✅ Block → Connections using an insecure protocol are blocked and a 426 Upgrade Required response is returned.
• ✅ Show Content → A browser update warning page is shown ("Your browser uses an insecure protocol. Please upgrade.").
• ✅ Advanced Traffic Inspection → Old protocol usage attempts are monitored and a legacy protocol exposure analysis is reported.

Scenario 2: PCI DSS Compliance Requirement (TLS 1.2+ Minimum)

Purpose: To meet the compliance requirements by detecting and blocking TLSv1.1 and lower protocols for conformity with the PCI DSS 3.2+ standards.

Configuration: SSL Protocol → TLSv1.1

Action Recommendations:

• ✅ Block → PCI DSS non-compliant protocols are blocked and a 403 Forbidden response is returned ("PCI DSS requires TLS 1.2+").
• ✅ Show Content → A compliance warning page is shown ("This service requires TLS 1.2 or higher for PCI DSS compliance").
• ✅ Advanced Traffic Inspection → PCI DSS violation attempts are monitored and compliance audit reports are created.

Scenario 3: TLSv1.3 Prioritization and Performance Optimization

Purpose: To provide a performance advantage by detecting modern clients using TLSv1.3 and routing them to optimized Backend Services.

Configuration: SSL Protocol → TLSv1.3

Action Recommendations:

• ✅ Add HTTP Header → The X-TLS-Version: 1.3 and X-Modern-Client: true headers are added, and the Backend Service performs modern protocol detection.
• ✅ Advanced Traffic Inspection → The TLSv1.3 adoption rate and version distribution analysis are reported.

Scenario 4: Gradual Protocol Migration (Deprecation Warnings)

Purpose: To provide a gradual migration by giving a warning to clients using protocols that will soon be removed, such as TLSv1.1.

Configuration: SSL Protocol → TLSv1.1

Action Recommendations:

• ✅ Add HTTP Header → The X-TLS-Deprecation: TLSv1.1 will be disabled on 2025-12-31 header is added, and the Backend Service can show a deprecation warning.
• ✅ Show Content → A migration notice banner is shown ("TLS 1.1 support ending soon. Please upgrade.").
• ✅ Advanced Traffic Inspection → Deprecated protocol usage trends and migration progress tracking are reported.

Scenario 5: Security Monitoring and Incident Detection

Purpose: To perform security incident tracking by detecting the attempts to use ancient protocols such as SSLv2/SSLv3, and to block repeated attempts.

Configuration: SSL Protocol → SSLv3 (a separate condition is defined for SSLv2). Note: if the TLS profile rejects these versions, the attempts are dropped at the handshake and never reach this condition.

Action Recommendations:

• ✅ Advanced Traffic Inspection → Ancient protocol attempts are monitored and reported as a critical security incident.
• ✅ Block → Potential attack attempts are blocked and a 403 Forbidden response is returned.
• ✅ Quarantine → IP addresses matching this condition are quarantined for 60 minutes (if a threshold based on the number of attempts is needed, the Quarantine action's own tracking condition is used).