SameSite default value of __VCAP_ID__ cookie changes with Chrome 80 release VMware Tanzu Application Service (TAS) for VMs

Products

• VMware Tanzu Application Service for VMs

Issue/Introduction

In the Chrome 80 release, Chrome changed the default behavior of SameSite. The default SameSitevalue is changed from None to Lax.

Given this change, the SameSite setting may impact the VMware Tanzu Application Service (TAS) for VMs cookie __VCAP_ID__,which is used for sticky session support.

With Chrome 80+ it will be set as Lax by default and it's currently not configurable.

Resolution

With Chrome 80, the default behavior changed for which conditions cookies are sent to the servers: 

• Cookies without a SameSite attribute are treated as SameSite=Lax - Before version 80 SameSite=None was the default.
• Cookies with SameSite=None must be set as Secure.
• During a transition period, Chrome will continue to send all cookies to servers, provided the cookies are no more than 2 minutes old [1].

In TAS for VMs, the cookie __VCAP_ID__ will be set for sticky sessions, when an app adds the JSESSIONID cookie [2]. Currently, the value of SameSite for the __VCAP_ID__ cookie is not directly configurable. What you will see is that the __VCAP_ID__ cookie inherits the value of Secure from the JSESSIONID and that SameSite is empty.

Before Chrome version 80, because SameSite for the __VCAP_ID__ cookie is set to None by default, the __VCAP_ID__ cookie will be sent by Chrome in a third-party context, to any hosts which don't match the cookie's domain.

Starting with Chrome version 80, because of SameSite default change from None to Lax and it's not configurable for  __VCAP_ID__ cookie, Chrome will send the cookie only to hosts which match the cookie's domain, as first-party cookies.

VMware is in the process of upgrading TAS for VMs to handle this change, but this will take time and will not happen before the release of Chrome 80.

We suggest reviewing any apps that depend on the sticky session support in TAS for VMs and confirm if the __VCAP_ID__ cookie is currently being used as third-party cookie. This won't work with Chrome 80 as it did for Chrome versions before Chrome 80.

[1] https://www.chromestatus.com/feature/5088147346030592 
[2] https://docs.cloudfoundry.org/concepts/http-routing.html#sessions

Checklist:

With Chrome 80, the default behaviour is changed under which conditions cookies are sent to the servers: 

• Cookies without a “SameSite” attribute are treated as “SameSite=Lax” (before version 80 “SameSite=None” was the default).
• Cookies with “SameSite=None” must be set as “Secure”.
• During a transition period, Chrome will continue to send all cookies to servers, provided the cookies are no more than 2 minutes old [1].

In Cloud Foundry, the cookie __VCAP_ID__ will be set for sticky sessions, when an app adds the JSESSIONID cookie[2]. Currently, the value of SameSite for the __VCAP_ID__ cookie is not directly configurable. What you will see is that the __VCAP_ID__ cookie inherits the value of Secure from the JSESSIONID and that SameSite is empty.

Before Chrome version 80, because SameSite for __VCAP_ID__ cookie is set to None by default, the __VCAP_ID__ cookie will be sent by Chrome in a third-party context, to any hosts which don't match the cookie's domain.

Starting with Chrome version 80, because of SameSite default change from None to Lax and it's not configurable for  __VCAP_ID__ cookie,  Chrome will send the cookie only to hosts which match the cookie's domain, as first-party cookies.

Pivotal is in the process of upgrading Cloud Foundry to handle this change, but this will take time and will not happen before the release of Chrome 80. Pivotal suggests reviewing your apps which depend on the sticky session support in Cloud Foundry and confirm if the __VCAP_ID__ cookie is currently being used as third-party cookie. This won't work with Chrome 80 as it did with before Chrome 80.

[1] https://www.chromestatus.com/feature/5088147346030592 

[2] https://docs.cloudfoundry.org/concepts/http-routing.html#sessions