FAQ
Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform

English

Türkçe

English

Türkçe

Appearance

Advanced

Can I reject requests whose SNI and Host Header do not match (domain fronting) (SNI/Host Validation)? ​

Short answer

Yes. SNI/Host Validation in the TLS Security Profile is turned on and the profile is assigned to the HTTP vService; requests whose SNI in the TLS handshake and HTTP Host header (excluding the port, case-insensitive) do not match are rejected with 421 Misdirected Request. No check is performed for clients that do not send SNI. It works only on the HTTP vService; on the L7 TCP vService, it is not applied because the Host header is not read. In WEB-CLI, the profile field is turned on with --sniHostValidation.

Problem: Another Site Is Accessed with the Certificate of One Domain Name ​

In domain fronting, the client uses one domain name (SNI) in the TLS handshake but requests another domain name (Host) in the HTTP request. In this way, security checks can be bypassed and another site on the same TR7 can be reached through the certificate of one site. SNI and Host must be required to be the same.

Solution: Two Methods ​

Your situationSuitable method
From the interfaceMethod 1: SNI/Host Validation
From the command lineMethod 2: WEB-CLI
  • How it works In every request, the Host header (with the port removed and converted to lowercase) is compared with the SNI; on a mismatch, the request is rejected with 421 without being forwarded to the Backend Service. In HTTP/2, only the related request is rejected and the browser retries the request over a separate connection; in HTTP/1.1, the connection is closed together with the response.
  • Where it is openedCertificates & PKI → TLS Security Profiles → Frontend-only Settings → SNI/Host Validation
  • Requirement An Encrypted (HTTPS) frontend row on the HTTP vService
  • vService type HTTP

Step-by-Step Configuration ​

1
Adım 1 Open the profile form

The Configuration Menu is opened with the TR7 logo at the bottom left; on the Certificates & PKI → TLS Security Profiles screen, the profile used by the vService is selected and Edit is clicked; for a new profile, Add is clicked and Security Profile Name is entered (how to add).

2
Adım 2 Turn on verification

In the Frontend-only Settings section, SNI/Host Validation is turned on (off by default).

3
Adım 3 Save the profile

Edit at the bottom of the form is clicked (Add for a new profile). If the profile is already assigned to vServices, the setting is applied to all of them and steps 4–6 are skipped.

4
Adım 4 Open the vService edit form

On the Load Balancer → Load Balancer vService List screen, the HTTP vService is selected and Edit is clicked.

5
Adım 5 Select the profile

In the Details panel, the SSL Security box under Frontend Settings is checked and the profile from step 3 is selected (profile selection on the vService). The box is listed only while an encrypted protocol is selected in at least one frontend row.

6
Adım 6 Save

Save is clicked. In a cluster setup, with the default auto-sync, the change is also sent to the peer device; if Manual Sync Mode is on, it is sent to the peer device manually.

Verification ​

1MismatchClient side

On a connection whose SNI is a.example.com, one request is sent with a different Host header and one with the same Host header.

Command: curl -sk https://a.example.com/ -H "Host: b.example.com" -o /dev/null -w "%{http_code}" · curl -sk https://a.example.com/ -H "Host: a.example.com:443" -o /dev/null -w "%{http_code}"

ExpectedThe first 421 · the second a normal response (a port difference does not count as a mismatch)

Method 2: WEB-CLI ​

  • How it works The SNI/Host Validation field of the profile is turned on with --sniHostValidation; if the profile is not assigned to the vService, it is assigned with --sslSecurity.
  • Where it is opened TR7 WEB-CLI → lb ssl-security update · lb service update
  • Requirement WEB-CLI access; an Encrypted (HTTPS) frontend row on the HTTP vService
  • vService type HTTP

Step-by-Step Configuration ​

1
Adım 1 Turn on the field in the profile

In place of <profile>, the profile is selected with Tab (Connection behavior):

text
lb ssl-security update id <profile> --sniHostValidation true
2
Adım 2 Assign the profile to the vService (if necessary)

If the profile is already selected on the vService, this step is skipped; in place of <vService>, the HTTP vService is selected with Tab:

text
lb service update id <vService> --sslSecurity <profile>

Verification ​

1RecordTR7 side

Command: lb ssl-security show <profile>

ExpectedsniHostValidation true
On the client side, the curl check in Method 1 is performed; a different Host header returns 421.

Common Mistakes ​

  • Expecting it on an L7 TCP vService. The Host header is read only on the HTTP vService; even if the setting is on in the profile, it is not applied on an L7 TCP vService.
  • Assuming clients that do not send SNI will be rejected. If there is no SNI, no check is performed; clients connecting with an IP address are not affected.
  • Trying to do the same job with the SSL SNI Info condition. The SSL SNI Info condition matches on connections where TLS is not decrypted on TR7; for comparing SNI and Host on an HTTP vService, this setting is used.
  • Worrying that HTTP/2 connection sharing will break. In HTTP/2, 421 is returned only to the related request; the browser retries the request over a separate connection.

How it is done in the documentation

Related questions