Note: In light of the extraordinary global circumstances due to COVID-19, Chrome has temporarily rolled back the enforcement of SameSite cookie labeling on Chrome 80 stable. An advance notice will be updated on Chromium blog when they plan to resume the gradual rollout, which is now aimed for over the summer: https://blog.chromium.org/2020/04/temporarily-rolling-back-samesite.html

The upcoming Chrome release, Chrome 80 is projected to change the default cross-domain behavior of cookies. This change will enhance the security though requires customers and partners to test Citrix ADC deployments that rely on cookies.

Impact on ADC

With Citrix ADC front ending an application, there can be 2 types of cookies in play:

• Case-1: APP cookie: cookie inserted by the back-end application server
• Case-2: ADC cookie: cookie inserted/owned by the Citrix ADC appliance

After the Chrome update, if an application requires Citrix ADC (or APP) cookie to be inserted by the browser in cross-site context (explained in background section below), the chrome browser will not do so in few scenarios with chrome 80 update.

• If APP cookies are missing, it can lead to breaking application flow. 
• If ADC cookie is missing in the subsequent request, ADC would treat it as a fresh user request and persistence is not honored resulting in break in application. 

Impact on Gateway and AAA

For all VPN and AAA deployments only within an iframe with cross-site context that require Citrix Gateway or AAA cookies to be inserted by the browser, Google chrome browser will not share cross site cookies after the update which will impact these specific deployments only and iframe component of the website will not load.
 
All VPN and AAA deployments with same site context with or without iframes do not have any impact and will work fine after the Chrome update. 

Background

Currently, typical browsers include the cookie in HTTP requests in 2 contexts.

• Same-site context: Here the user is requesting the browser to take him/her to a specific domain for which the browser has the cookie stored previously.
• Cross-site context: Here a third party website is redirecting the user to a domain for which the browser has the cookie stored and the browser includes the cookie while requesting for the web page.

In cross-site context, there can be Cross Site Request Forgery (CSRF) attacks which can lead to an attacker stealing user's session to perform undesired actions on user's behalf. To prevent this, RFC6265bis recommends adding a new attribute "SameSite" in the cookie which indicates the browser whether the cookie can be used for cross-site context or only for same-site context. Also if an application intends to be accessed in cross-site context then it can do so only via https connection.

The SameSite attribute can take the below options.

• SameSite=None; Secure   
  • Indicates the browser to use cookie in cross-site context only on secure connections.
• SameSite=Lax
  • Indicates the browser to use cookie for requests on the same domain and for cross-site only safe HTTP methods like GET request can use the cookie.
• SameSite=Strict
  • Use the cookie only when user is requesting for the domain explicitly.

Note: If there is no SameSite attribute in the cookie, the Chrome browser assumes the functionality of SameSite=Lax from Feb 2020. The current default value of SameSite setting is None which allows the browser to use cookies in third party context. 

The permanent fix for the configuration level options to accommodate this change will be available in versions 13.0, 12.1, 12.0 and 11.1 and following are the targeted dates.

ADC Versions	Release Dates	Status
13.0 52.24	March 24th 2020	Released
12.1 55.24	March 6th  2020	Released
12.0 63.21	July 7th 2020	Released
11.1 64.11	March 25th 2020	Released

The following are the available workarounds:

Workarounds

Workaround through Chrome

In Chrome 80 there is an option which will allow you to revert to the legacy cookie behavior.  This will be available for at least 12 months after the release of Chrome 80 stable.
Refer to SameSite Updates for more information. 

Workaround Steps for Case: 1 App cookie

One can configure a response-based rewrite policy to look into “Set-cookie” header in the response sent by the backend server and append the “SameSite” cookie attribute. 

Sample rewrite policy looks like:

add rewrite action rewrite_http_header replace_all http.RES.full_Header "\"SameSite=None; Secure; path=/\"" -search "regex(re!(path=/\\; SameSite)|(path=/)!)"
add rewrite policy append_samesite_cookie "http.RES.HEADER(\"Set-Cookie\").EXISTS" rewrite_http_header

above rewrite policies needs to be bound application specific virtual server on Citrix ADC.

Workaround Steps for Case: 2 ADC cookie (Persistence Use case)

Currently there are two workarounds to prevent breakage if any (due to the chrome update) to applications with COOKIEINSERT persistence configured on LB vserver.

1. Use response RULE based persistence

If the back end application sends a unique cookie for each of the client session, Citrix ADC can use this unique cookie value as a key and create a RULE based persistence entry storing the back end server information corresponding to the cookie received. When the client request comes back with this Cookie, Citrix ADC will use the cookie value as the key and fetch the corresponding back end server to forward the request, hence maintaining the stickiness as achieved by COOKIEINSERT persistence. This approach works only if the back end server sends a unique Cookie key:value pair for each client in the response.

Below is a sample config where back end server sends cookie with the key as SESSIONID. The SESSIONID in the below config must be replaced with the unique cookie key sent by the back end.

set lb vserver lbvs -persistenceType RULE -rule "HTTP.REQ.COOKIE.VALUE(\"SESSIONID\")" -resRule "HTTP.RES.SET_COOKIE.COOKIE(\"SESSIONID\").VALUE(0)"

Note: The persistence timeout value must be chosen appropriately based on the application requirement.

2. Two Tier topology with a new Citrix ADC front ending the existing Citrix ADCs

Customer can have a two-tier topology with a new Citrix ADC front ending the traffic for the tier-2 Citrix ADC (existing Citrix ADC). The first tier Citrix ADC does response rewrite to include the SameSite attribute for all the cookies received from the tier-2 Citrix ADC.
There are no configuration changes required on the tier-2 Citrix ADC. 

Below is a sample configuration on the tier-1 Citrix ADC.

enable feature lb rewrite
add lb vserver tier-1-lb <protocol> <IP> <port>
add service tier-2-lb-svc <tier-2-vserver-IP> <tier-2-vserver-protocol> <tier-2-vserver-port>
bind lb vserver tier-1-lb tier-2-lb-svc
add rewrite action rewrite_http_header replace_all http.RES.full_Header "\"SameSite=None; Secure; path=/\"" -search "regex(re!(path=/\\; SameSite)|(path=/)!)"
add rewrite policy append_samesite_cookie "http.RES.HEADER(\"Set-Cookie\").EXISTS" rewrite_http_header
bind lb vserver tier-1-lb -policyname append_samesite_cookie -priority 10 -type RESPONSE

Note:- This should work even if the back end server does not include any cookie of its own.

We are reviewing on any other ADC use case which may have impact due to the change in default Chrome behavior, Document will be updated with Impact and mitigation steps accordingly.