on 10-Feb-2020 20:19
A bunch of us have been refining approaches to help customers handle the new browser enforcement of the HTTP cookie SameSite attribute.
I think we have a pretty solid approach now to handle compatible and incompatible user-agents.
The iRule:
The iRule uses Simon Kowallik's updated string matching logic to handle the incompatible user-agent from Chomium's blog: https://www.chromium.org/updates/same-site/incompatible-clients
Note this iRule only modifies BIG-IP and web application cookies found in Set-Cookie headers. It does not attempt to modify cookies that the BIG-IP or web application sets via Javascript or other methods. BIG-IP ASM is known to set some cookies via Javascript. If you require support for this, please open a case with F5 support (https://support.f5.com) and request your case be added to:
BZ875909: Allow admin configuration of SameSite attribute on ASM system cookies set via Set-Cookie and Javascript
samesite_security: Set this to Strict, Lax or None. The description for these values is in the iRule quoted below:
# Set BIG-IP and app cookies found in Set-Cookie headers using this iRule to: # # none: Cookies will be sent in both first-party context and cross-origin requests; # however, the value must be explicitly set to None and all browser requests must # follow the HTTPS protocol and include the Secure attribute which requires an encrypted # connection. Cookies that don't adhere to that requirement will be rejected. # Both attributes are required together. If just None is specified without Secure or # if the HTTPS protocol is not used, the third-party cookie will be rejected. # # lax: Cookies will be sent automatically only in a first-party context and with HTTP GET requests. # SameSite cookies will be withheld on cross-site sub-requests, such as calls to load images or iframes, # but will be sent when a user navigates to the URL from an external site, e.g., by following a link. # # strict: browser never sends cookies in requests to third party domains # # Above definitions from: https://docs.microsoft.com/en-us/microsoftteams/platform/resources/samesite-cookie-update # # Note: this iRule does not modify cookies set on the client using Javascript or other methods outside of Set-Cookie headers! set samesite_security "none"
Uncomment the next command if you're using this iRule on an APM virtual server with an access profile:
# Uncomment when using this iRule on an APM-enabled virtual server so the MRHSession cookies will be rewritten # The iRule cannot be saved on a virtual server with this option uncommented if there is no Access profile also enabled #ACCESS::restrict_irule_events disable
Now define whether you want to rewrite all web application and BIG-IP cookies found in the Set-Cookie header(s). Set this to 1 to rewrite SameSite on all cookies in Set-Cookie headers. Else, if you want to define specifically named or prefixed cookies, set this option to 0, and proceed to the next two config options, #2 and #3
# 1. If you want to set SameSite on all BIG-IP and web application cookies for compliant user-agents, set this option to 1 # Else, if you want to use the next two options for rewriting explicit named cookies or cookie prefixes, set this option to 0 set set_samesite_on_all 0
If you don't want to rewrite all cookies using option #1 above, you can choose to rewrite explicitly named cookies in option #2. Set the exact cookie names in the named_cookie list. Replace MRHSession and LastMRH_Session, which are examples of the cookies APM uses. If you do not want to rewrite exact cookie names, comment out the first example and uncomment the second example "set named_cookies {}"
# 2. Rewrite SameSite on specific named cookies # # To enable this, list the specific named cookies in the list command and comment out the second set command below # To disable this, set this variable to {} and comment out the first set command below set named_cookies [list {MRHSession} {LastMRH_Session}] #set named_cookies {}
If you don't want to rewrite all cookies using option #1 above, you can choose to rewrite cookies using a prefix in option #3. Set the cookie name prefixes in the named_cookie list. Replace BIGipServer and TS, which are examples of the cookie prefixes LTM uses for persistence and ASM uses for session tracking, with the prefixes of the cookie names you want to rewrite. If you do not want to rewrite using cookie name prefixes, comment out the first example and uncomment the second example "set named_cookies {}"
# 3. Rewrite cookies with a prefix like BIG-IP persistence cookies # To enable this, list the cookie name prefixes in the list command and comment out the second set command below # To disable this, set this variable to {} and comment out the first set command below set cookie_prefixes [list {BIGipServer} {TS}] #set cookie_prefixes {}
If your application or BIG-IP configuration sets cookies in the Set-Cookie headers with SameSite=None, incompatible user-agents will either reject the cookie or treat the cookie as if it was set for SameSite=Strict (https://www.chromium.org/updates/same-site/incompatible-clients).
You can set remove_samesite_for_incompatible_user_agents to 1 to have this iRule remove SameSite attributes from all cookies sent to incompatible browsers.
# For incompatible user-agents, this iRule can remove the SameSite attribute from all cookies sent to the client via Set-Cookie headers # This is only necessary if BIG-IP or the web application being load balanced sets SameSite=None for all clients # set to 1 to enable, 0 to disable set remove_samesite_for_incompatible_user_agents 1
While testing, you can set samesite_debug to 1 to test and get debug written to /var/log/ltm. Make sure to disable this option when you're done testing, before putting the iRule into production!
# Log debug to /var/log/ltm? 1=yes, 0=no # set to 0 after testing set samesite_debug 1
(Updates can be found in the irules-toolbox repo on GitHub. This specific version is for v12+, but there is a pre-v12 version in the repo as well.)
# iRule: samesite_cookie_handling # author: Simon Kowallik # version: 1.3 # # History: version - author - description # 1.0 - Simon Kowallik - initial version # 1.1 - Aaron Hooley - updated to add support for setting SameSite to Strict|Lax|None for BIG-IP and app cookies in Set-Cookie headers # - Add option to remove SameSite=None cookies for incompatible browsers # 1.2 - Aaron Hooley - Added option to rewrite all cookies without naming them explicitly or with prefixes # 1.3 - Aaron Hooley - set samesite_compatible to 0 by default instead of a null string # # What the iRule does: # Sets SameSite to Strict, Lax or None (and sets Secure when SameSite=None) for compatible user-agents # Optionally removes SameSite attribute from all cookies for incompatible user-agents so they'll handle cookies as if they were SameSite=None # # The iRule should work for: # - LTM for web app cookies and persistence cookies, except those that the web app sets via Javascript # - ASM for web app cookies and all ASM cookies except those that ASM or the web app sets via Javascript # - APM for web app cookies and all APM cookies you configure in the config variable $named_cookies, except those that the web app sets via Javascript # # The iRule requires BIG-IP v12 or greater to use the HTTP::cookie attribute command # # RFC "standards" # https://tools.ietf.org/html/draft-west-cookie-incrementalism-00 # https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-05 # further reading: # https://web.dev/samesite-cookies-explained/ # https://web.dev/samesite-cookie-recipes/ # https://blog.chromium.org/2019/10/developers-get-ready-for-new.html # https://www.chromium.org/updates/same-site # https://www.chromium.org/updates/same-site/incompatible-clients proc checkSameSiteCompatible {user_agent} { # Procedure to check if a user-agent supports SameSite=None on cookies # # usage: # set isSameSiteCompatible [call checkSameSiteCompatible {User-Agent-String}] # # check for incompatible user-agents: https://www.chromium.org/updates/same-site/incompatible-clients # based on https://devcentral.f5.com/s/articles/HTTP-cookie-SameSite-test-detection-of-browsers-with-incompatible-SameSite-None-handling switch -glob -- [set user_agent [string tolower $user_agent]] { {*chrome/5[1-9].[0-9]*} - {*chrome/6[0-6].[0-9]*} - {*chromium/5[1-9].[0-9]*} - {*chromium/6[0-6].[0-9]*} - {*ip?*; cpu *os 12*applewebkit*} - {*macintosh;*mac os x 10_14*version*safari*} - {mozilla*macintosh;*mac os x 10_14*applewebkit*khtml, like gecko*} { # no samesite support return 0 } {*ucbrowser/*} { switch -glob -- $user_agent { {*ucbrowser/[1-9].*} - {*ucbrowser/1[0-1].*} - {*ucbrowser/12.[0-9].*} - {*ucbrowser/12.1[0-1].*} - {*ucbrowser/12.12.*} - {*ucbrowser/12.13.[0-2]*} { # no samesite support return 0 } } } } # If the current user-agent didn't match any known incompatible browser list, assume it can handle SameSite=None return 1 # CPU Cycles on Executing (>100k test runs) # Average 22000-42000 (fastest to slowest path) # Maximum 214263 # Minimum 13763 } # the iRule code when CLIENT_ACCEPTED priority 100 { # Set BIG-IP and app cookies found in Set-Cookie headers using this iRule to: # # none: Cookies will be sent in both first-party context and cross-origin requests; # however, the value must be explicitly set to None and all browser requests must # follow the HTTPS protocol and include the Secure attribute which requires an encrypted # connection. Cookies that don't adhere to that requirement will be rejected. # Both attributes are required together. If just None is specified without Secure or # if the HTTPS protocol is not used, the third-party cookie will be rejected. # # lax: Cookies will be sent automatically only in a first-party context and with HTTP GET requests. # SameSite cookies will be withheld on cross-site sub-requests, such as calls to load images or iframes, # but will be sent when a user navigates to the URL from an external site, e.g., by following a link. # # strict: browser never sends cookies in requests to third party domains # # Above definitions from: https://docs.microsoft.com/en-us/microsoftteams/platform/resources/samesite-cookie-update # # Note: this iRule does not modify cookies set on the client using Javascript or other methods outside of Set-Cookie headers! set samesite_security "none" # Uncomment when using this iRule on an APM-enabled virtual server so the MRHSession cookies will be rewritten # The iRule cannot be saved on a virtual server with this option uncommented if there is no Access profile also enabled #ACCESS::restrict_irule_events disable # 1. If you want to set SameSite on all BIG-IP and web application cookies for compliant user-agents, set this option to 1 # Else, if you want to use the next two options for rewriting explicit named cookies or cookie prefixes, set this option to 0 set set_samesite_on_all 0 # 2. Rewrite SameSite on specific named cookies # # To enable this, list the specific named cookies in the list command and comment out the second set command below # To disable this, set this variable to {} and comment out the first set command below set named_cookies [list {MRHSession} {LastMRH_Session}] #set named_cookies {} # 3. Rewrite cookies with a prefix like BIG-IP persistence cookies # To enable this, list the cookie name prefixes in the list command and comment out the second set command below # To disable this, set this variable to {} and comment out the first set command below set cookie_prefixes [list {BIGipServer} {TS}] #set cookie_prefixes {} # For incompatible user-agents, this iRule can remove the SameSite attribute from all cookies sent to the client via Set-Cookie headers # This is only necessary if BIG-IP or the web application being load balanced sets SameSite=None for all clients # set to 1 to enable, 0 to disable set remove_samesite_for_incompatible_user_agents 1 # Log debug to /var/log/ltm? 1=yes, 0=no # set to 0 after testing set samesite_debug 1 # You shouldn't have to make changes to configuration below here # Track the user-agent and whether it supports the SameSite cookie attribute set samesite_compatible 0 set user_agent {} if { $samesite_debug }{ set prefix "[IP::client_addr]:[TCP::client_port]:" log local0. "$prefix [string repeat "=" 40]" log local0. "$prefix \$samesite_security=$samesite_security; \$set_samesite_on_all=$set_samesite_on_all; \$named_cookies=$named_cookies; \$cookie_prefixes=$cookie_prefixes, \ \$remove_samesite_for_incompatible_user_agents=$remove_samesite_for_incompatible_user_agents" } } # Run this test event before any other iRule HTTP_REQUEST events to set the User-Agent header value # Comment out this event when done testing user-agents #when HTTP_REQUEST priority 2 { # known compatible # HTTP::header replace user-agent {my compatible user agent string} # known INcompatible # HTTP::header replace user-agent {chrome/51.10} #} # Run this iRule before any other iRule HTTP_REQUEST events when HTTP_REQUEST priority 100 { # If we're setting samesite=none, we need to check the user-agent to see if it's compatible if { not [string equal -nocase $samesite_security "none"] }{ # Not setting SameSite=None, so exit this event return } # Inspect user-agent once per TCP session for higher performance if the user-agent hasn't changed if { $samesite_compatible == 0 or $user_agent ne [HTTP::header value {User-Agent}]} { set user_agent [HTTP::header value {User-Agent}] set samesite_compatible [call checkSameSiteCompatible $user_agent] if { $samesite_debug }{ log local0. "$prefix Got \$samesite_compatible=$samesite_compatible and saved current \$user_agent: $user_agent" } } } # Run this response event with priority 900 after all other iRules to parse the final cookies from the application and BIG-IP when HTTP_RESPONSE_RELEASE priority 900 { # Log the pre-existing Set-Cookie header values if { $samesite_debug }{ log local0. "$prefix Set-Cookie value(s): [HTTP::header values {Set-Cookie}]" } if { $samesite_compatible } { # user-agent is compatible with SameSite=None, set SameSite on matching cookies if { $set_samesite_on_all }{ if { $samesite_debug }{ log local0. "$prefix Setting SameSite=$samesite_security on all cookies and exiting" } foreach cookie [HTTP::cookie names] { if { $samesite_debug }{ log local0. "$prefix Set SameSite=$samesite_security on $cookie" } # Remove any prior instances of SameSite attributes HTTP::cookie attribute $cookie remove {samesite} # Insert a new SameSite attribute HTTP::cookie attribute $cookie insert {samesite} $samesite_security # If samesite attribute is set to None, then the Secure flag must be set for browsers to accept the cookie if {[string equal -nocase $samesite_security "none"]} { HTTP::cookie secure $cookie enable } } # Exit this event in this iRule as we've already rewritten all cookies with SameSite return } # Match named cookies exactly if { $named_cookies ne {} }{ foreach cookie $named_cookies { if { [HTTP::cookie exists $cookie] } { # Remove any pre-existing SameSite attributes from this cookie as most clients use the most strict value if multiple instances are set HTTP::cookie attribute $cookie remove {SameSite} # Insert the SameSite attribute HTTP::cookie attribute $cookie insert {SameSite} $samesite_security # If samesite attribute is set to None, then the Secure flag must be set for browsers to accept the cookie if {[string equal -nocase $samesite_security "none"]} { HTTP::cookie secure $cookie enable } if { $samesite_debug }{ log local0. "$prefix Matched explicitly named cookie $cookie, set SameSite=$samesite_security" } if { $samesite_debug }{ log local0. "$prefix " } } } } # Match a cookie prefix (cookie name starts with a prefix from the $cookie_prefixes list) if { $cookie_prefixes ne {} }{ foreach cookie [HTTP::cookie names] { foreach cookie_prefix $cookie_prefixes { if { $cookie starts_with $cookie_prefix } { # Remove any pre-existing SameSite attributes from this cookie as most clients use the most strict value if multiple instances are set HTTP::cookie attribute $cookie remove {SameSite} # Insert the SameSite attribute HTTP::cookie attribute $cookie insert {SameSite} $samesite_security # If samesite attribute is set to None, then the Secure flag must be set for browsers to accept the cookie if { [string equal -nocase $samesite_security "none"] } { HTTP::cookie secure $cookie enable } if { $samesite_debug }{ log local0. "$prefix Matched prefixed cookie $cookie, with prefix $cookie_prefix, set SameSite=$samesite_security, breaking from loop" } break } } } } } else { # User-agent can't handle SameSite=None if { $remove_samesite_for_incompatible_user_agents }{ # User-agent can't handle SameSite=None, so remove SameSite attribute from all cookies if SameSite=None # This will use CPU cycles on BIG-IP so only enable it if you know BIG-IP or the web application is setting # SameSite=None for all clients including incompatible ones foreach cookie [HTTP::cookie names] { if { [string tolower [HTTP::cookie attribute $cookie value SameSite]] eq "none" }{ HTTP::cookie attribute $cookie remove SameSite if { $samesite_debug }{ log local0. "$prefix Removing SameSite for incompatible client from cookie=$cookie" } } } } } # Log the modified Set-Cookie header values if { $samesite_debug }{ log local0. "$prefix Final Set-Cookies: [HTTP::header values {Set-Cookie}]" } }
if you're on a version that doesn't support the HTTP::cookie attribute method (v11 mainly) here's a way to add the attribute it. Ideally you'd upgrade to v12+ but if that's not an option it does add the attribute. Obviously change SameSitee=none to
when HTTP_RESPONSE {
set COOKIE_VAL [HTTP::header values "Set-Cookie"]
HTTP::header remove "Set-Cookie"
foreach COOKIE_NAME $COOKIE_VAL {
HTTP::header insert "Set-Cookie" "${COOKIE_NAME}; SameSite=none"
HTTP::cookie secure ${COOKIE_NAME} enable
}
}
the above and this could probably be integrated together for older versions until they can upgrade.
Hi! Just don't forget to set Secure attribute with SameSite=None as well, otherwise it will have no effect.
See: https://tools.ietf.org/html/draft-west-cookie-incrementalism-00#section-4.2
good catch, I initially had the cookie secure in there and accidently removed it when I was removing the log lines before posting. Added it back in
Unfortunately the behaviour isn't consistent across incompatible clients. SameSite=None wasn't introduced in the first drafts of the RFC, which might be the reason why there is inconsistent behaviour, which ranges from treating SameSite=None as SameSite=strict to ignoring the cookie.
Here is the list of incompatible user-agents according to google chromium:
https://www.chromium.org/updates/same-site/incompatible-clients
Here is a quick read on this topic:
https://www.linkedin.com/pulse/samesite-cookies-your-legacy-web-apps-simon-kowallik
I tried creating an irule with just the following entry but seems it doesn't fix the samesite concern:
when HTTP_RESPONSE {
set COOKIE_VAL [HTTP::header values "Set-Cookie"]
HTTP::header remove "Set-Cookie"
foreach COOKIE_NAME $COOKIE_VAL {
HTTP::header insert "Set-Cookie" "${COOKIE_NAME}; SameSite=none"
HTTP::cookie secure ${COOKIE_NAME} enable
}
}
when HTTP_RESPONSE {
HTTP::header replace Set-Cookie "[HTTP::header Set-Cookie]; HttpOnly;SameSite=none; Secure"
}
Is there something I am missing?
Thanks!
In our situation we are only interested in fixing the BigIP cookie for sticky load balancing. If that's the case wouldn't it make more sense delay the call to checkSameSiteCompatible until we are processing the response. In that way we can avoid doing all the regex compares, if there are no cookies present in the response that we want to change. It seems wasteful for me to be processing all those regexes for each request when there are not relevant cookies.
If that's the case, even with all these options to set all cookies etc, I think there should be a way to store off the user agent value in a variable when processing the request, then use it in the response while maintaining a flag that will tell you if you already checked. For instance we can initialize same_site_compatible to -1 which tells us it has not yet been checked. This way we can arrange the logic during the response processing to only check the user agent once for the first occurence of a cookie we want to process.
I'm not proficient in writing IRules so maybe I'm missing something important here, so I would appreciate feedback letting me know if my idea has flaws besides the obvious one of adding some more complexity to the logic.
Thanks,
Mark
This iRule seems not to be compatible with 15.1.1 build 0.0.6 as it gives this error to LTM logs:
TCL error: /Common/Add_SameSite_cookie_v2 <HTTP_RESPONSE_RELEASE> - Can't call after responding - ERR_NOT_SUPPORTED (line 1) invoked from within "HTTP::cookie names"
Any ideas on how to fix this?
Hi and ,
Do you have APM enabled on the virtual server? Or another iRule that is sending an HTTP response?
I believe the issue is described in K23237429:
K23237429: TCL error: ERR_NOT_SUPPORTED after upgrade to version 14.1.0 or later
https://support.f5.com/csp/article/K23237429
Once I understand the configuration that's causing the TCL error, I can try to suggest a fix for it.
Thanks, Aaron
We have APM enabled on this affected virtual server and also another iRule. The reason we were using the SameSite iRule is that in this case we are using external IdP and when the SAML response in SLO comes back, we need to modify the APM cookie SameSite values to None in order it to work. I combined the two iRules together but never got it to work and always got the same error i posted here earlier. The workaround we came up was to do a redirect after the SAML SLO response and removed that SameSite iRule code lines from the virtual server. The workaround is not ideal, but at least we got it working again. I think I have read somewhere that the APM SameSite values are modifiable from APM profile in 16.x version but we are not yet ready to upgrade to that release.
Good day,
Yes APM is enabled on the virtual server. We have another iRule that uses HTTP response. This was added (2/3 years ago) to fix issues opening links to this site from MS Office documents. I have removed this iRule and am still receiving the same TCL error.
when HTTP_REQUEST {
HTTP::header insert x-sap-webdisp-ap "HTTPS=443"
switch -glob -- [string tolower [HTTP::header "User-Agent"]] {
"*word*" -
"*excel*" -
"*office upload*" -
"*office existence discovery*" -
"*office protocol discovery*" -
"*soap toolkit*" -
"*ms-office*" -
"*microsoft office onenote*" -
"*webdav-miniredir*" -
"*frontpage*" -
"*msfrontpage*" - "*shareplus*" { HTTP::respond 200 } }
}
Example Errors:
Jan 4 08:45:54 <HOSTNAME> err tmm3[22340]: 01220001:3: TCL error: /Common/<IRULE_NAME> <HTTP_RESPONSE_RELEASE> - Can't call after responding - ERR_NOT_SUPPORTED (line 1) invoked from within "HTTP::cookie exists $cookie" ("foreach" body line 2) invoked from within "foreach cookie $named_cookies { if { [HTTP::cookie exists $cookie] } { # Remove any pre-existing SameSite attributes from this cookie as most..."
Jan 4 08:45:54 <HOSTNAME> err tmm3[22340]: 01220001:3: TCL error: <IRULE_NAME> <HTTP_RESPONSE_RELEASE> - Can't call after responding - ERR_NOT_SUPPORTED (line 29) invoked from within "HTTP::cookie exists $cookie" ("foreach" body line 2) invoked from within "foreach cookie $named_cookies { if { [HTTP::cookie exists $cookie] } { # Remove any pre-existing SameSite attributes from this cookie as most..."
Thanks,
Jason
Thanks for your replies and . Could you add this line to the samesite iRule just after the HTTP_RESPONSE_RELEASE line?
Look for this line (line 188 in https://github.com/f5devcentral/irules-toolbox/blob/master/security/http/cookies/samesite-attributes...😞
# Run this response event with priority 900 after all other iRules to parse the final cookies from the application and BIG-IP
when HTTP_RESPONSE_RELEASE priority 900 {
And add this return command after it, as listed below:
# Exit this event if another iRule has already sent an HTTP response (F5 article K23237429)
if {[HTTP::has_responded]}{return}
Please test this on a separate non-production virtual server or during a maintenance window in case there are any issues.
Thanks, Aaron
Hello, having a Policy with redirection to another URL, the SameSite irule does not work and sends Reset, we had to separate these redirects in another irule to solve it.
Who knows why this behavior?
Thanks
Hi Juan,
Are you using the latest version of the iRule which includes these lines?
https://github.com/f5devcentral/irules-toolbox/blob/master/security/http/cookies/samesite-attributes.tcl
# 1.5 - Aaron Hooley - Fixed issue noted in https://support.f5.com/csp/article/K23237429 by disabling the iRule if another response has already been sent
# Run this response event with priority 900 after all other iRules to parse the final cookies from the application and BIG-IP
when HTTP_RESPONSE_RELEASE priority 900 {
# Don't do anything if a response has already been triggered for this request
if {[HTTP::has_responded]}{
if { $samesite_debug }{ log local0. "$prefix Exiting as response has already been triggered by another configuration option" }
# exit this event in this iRule
return
}
Aaron
Hello ,
Nice Irule and work but I get an issue with it, I have a F5 with version BIG-IP 13.1.3.2 Build 0.0.4 Point Release 2.
I get the error below:
So regarding the documentation, the 'HTTP::has_responded' variable appears after version BIGIP-14.0.
Then I've checked the GitHub repo dedicated to prior version 12 (https://github.com/f5devcentral/irules-toolbox/blob/master/security/http/cookies/samesite-attributes...) and I can see the the condition below is not taken into consideration:
when HTTP_RESPONSE_RELEASE priority 900 {
# Don't do anything if a response has already been triggered for this request
if {[HTTP::has_responded]}{
if { $samesite_debug }{ log local0. "$prefix Exiting as response has already been triggered by another configuration option" }
# exit this event in this iRule
return
}
So I have decided to test the Irule (https://github.com/f5devcentral/irules-toolbox/blob/master/security/http/cookies/samesite-attributes...) removing the part below:
# Don't do anything if a response has already been triggered for this request
if {[HTTP::has_responded]}{
if { $samesite_debug }{ log local0. "$prefix Exiting as response has already been triggered by another configuration option" }
# exit this event in this iRule
return
}
It seems to work correctly, but could you confirm if doing that we can get side effects or not, what could be the exact impact ?
Do you have any advice to replace it otherwise by another method ?
Many thanks in advance.
Have a nice day,
Alex
Hi ,
TMOS version 13.x doesn't support `HTTP::has_responded`, this command was introduced in TMOS version 14.1.
The below support article has detailed information about the background.
K23237429: TCL error: ERR_NOT_SUPPORTED after upgrade to version 14.1.0 or later
If this is the only iRule attached to the virtual server and you don't use LTM policies there is nothing to worry about. If you do, just check if any of the criteria applies to you and re-arrange the iRule code accordingly to be prepared for a later TMOS upgrade.
Regards
Simon
FYI, Firefox just released SameSite cookie control in v96.0 (Jan 11, 2022), and it broke login to Outlook (2016) Web Access for us. Have been using your iRule for Chrome, so just added this agent line, and now we are all good again:
{*firefox/9[0-9].[0-9]*} -
That should cover any Firefox version from v90.0 - v99.9.
Hope that might help someone else.
/ Per