For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

SSL Orchestrator Use Case: Inbound SNI Switching

Introduction SSLO will generate a single set of SSL profiles for use in a topology. It may be useful, especially in an inbound gateway mode, to process traffic to multiple sites, requiring different...
Published Feb 17, 2021
Version 1.0
BIG-IP
inbound
iRules
security
series-ssl-orchestrator-advanced-use-cases
sni
sslo
switch
KevinGallaugher's avatar
Icon for Employee rankEmployee
Technical Marketing Engineer for SSL Orchestrator. I have over 25 years experience in Cybersecurity, with over 15 years spent as a Technical Marketing Engineer. Prior to F5 I worked at Blue Coat, Gigamon and Fortinet.
View Profile
KevinGallaugher's avatar
Icon for Employee rankEmployee
Technical Marketing Engineer for SSL Orchestrator. I have over 25 years experience in Cybersecurity, with over 15 years spent as a Technical Marketing Engineer. Prior to F5 I worked at Blue Coat, Gigamon and Fortinet.
View Profile
KevinGallaugher's avatar
KevinGallaugher
Icon for Employee rankEmployee
Sep 09, 2021

Hi Torti, I got an update on this from an expert and here's what he had to say:

So as it turns out, the answer to Torti’s question is ‘no’. The ‘cSS’ binary scan flags are only looking at the outer layer of the TLS packet, and this is ALWAYS 1.0 (769). To get to the inner/actual TLS version you have to add a few more binary scan flags. But that’s not important for fetching the Server Name Indication extension. Plus, TLS 1.3 identifies itself in the TLS extensions, so a TLS 1.3 handshake will have 1.0 as the outer version (same as the others), and 1.2 as the inner version (for backward compatibility). 

 

Otherwise, this iRule works natively for TLS 1.3 as long as encrypted client hello (ECH) isn’t enabled.