Forum Discussion
Cookie Encryption
- Jul 06, 2021
As Rob mentioned in his response, the cookie encryption options in an HTTP profile and a cookie persistence profile have two different scopes. Let's start with the HTTP profile's encryption options.
The Encrypt Cookies option allows you to name the specific cookies whose values you want the system to encrypt between the BIG-IP system and the client. You can identify cookies sent by the application server in the server response and cookies sent by the BIG-IP system, such as the "special cookie" sent by the system when a cookie persistence profile is in use on the virtual server. But each cookie must be identified by its name, which can be somewhat cumbersome when the target is a persistence cookie and persistence applies across multiple pools, each with a different name.
In v11.5, F5 added encryption options to the cookie persistence profile. The scope of these options is only for the "special cookie" sent as part of cookie persistence. In other words, while the HTTP profile encryption options apply to all cookies identified, the cookie persistence profile encryption options apply only to the special persistence cookie, not to any other BIG-IP system cookies or to cookies sent in the server response. And the options for configuring encryption are far more granular in the cookie persistence profile than in the HTTP profile.
For example, the HTTP profile only allows you to identify the cookies that are to be encrypted by name and to identify the encryption passphrase to use. In contrast, the encryption options in the cookie persistence profile allow you to:
- Override the system default "special persistence cookie" name BIGipServer<pool-name> with a name of your choosing (Cookie Name option)
- If using the default cookie name, control whether the <pool-name> portion of the cookie name is encrypted or not (Default Cookie Encrypt Pool-Name); this is disabled by default
- Control whether the special persistence cookie value must always be encrypted (required) or not (disabled), or whether a mix of encrypted and unencrypted special cookie persistence values is allow (preferred)
If you wanted to manage all cookie encryption, including the special persistence cookie, from an HTTP profile, but you did not want to have to enter the default cookie name for each pool where persistence applies (in other words, BIGipServerPool1, BIGipServerPool2, and so on), you could specify a custom Cookie Name in the cookie persistence profile and enter that single name into the HTTP profile's Encrypt Cookies option. Or, you can use the cookie persistence profile to specify encryption options for the special persistence cookie while using the HTTP profile to specify encryption options for any other cookies.
I did a quick test to see what the effect might be if I used both methods together - a cookie persistence profile with a custom Cookie Name (set to MyCookie) and encryption enabled, and an HTTP profile with Encrypt Cookies set to MyCookie and an encryption passphrase, and it "worked" (meaning no errors). But I can't tell if the HTTP profile overrode the cookie persistence profile or if encryption was applied twice, but I do know it is one or the other as the cookie's encrypted value changed when I put the custom HTTP profile on and took it off.
My recommendation is to manage everything to do with persistence cookie encryption from the cookie persistence profile, and use the HTTP profile to encrypt other cookies that the application doesn't already protect from information leakage by itself.
As Rob mentioned in his response, the cookie encryption options in an HTTP profile and a cookie persistence profile have two different scopes. Let's start with the HTTP profile's encryption options.
The Encrypt Cookies option allows you to name the specific cookies whose values you want the system to encrypt between the BIG-IP system and the client. You can identify cookies sent by the application server in the server response and cookies sent by the BIG-IP system, such as the "special cookie" sent by the system when a cookie persistence profile is in use on the virtual server. But each cookie must be identified by its name, which can be somewhat cumbersome when the target is a persistence cookie and persistence applies across multiple pools, each with a different name.
In v11.5, F5 added encryption options to the cookie persistence profile. The scope of these options is only for the "special cookie" sent as part of cookie persistence. In other words, while the HTTP profile encryption options apply to all cookies identified, the cookie persistence profile encryption options apply only to the special persistence cookie, not to any other BIG-IP system cookies or to cookies sent in the server response. And the options for configuring encryption are far more granular in the cookie persistence profile than in the HTTP profile.
For example, the HTTP profile only allows you to identify the cookies that are to be encrypted by name and to identify the encryption passphrase to use. In contrast, the encryption options in the cookie persistence profile allow you to:
- Override the system default "special persistence cookie" name BIGipServer<pool-name> with a name of your choosing (Cookie Name option)
- If using the default cookie name, control whether the <pool-name> portion of the cookie name is encrypted or not (Default Cookie Encrypt Pool-Name); this is disabled by default
- Control whether the special persistence cookie value must always be encrypted (required) or not (disabled), or whether a mix of encrypted and unencrypted special cookie persistence values is allow (preferred)
If you wanted to manage all cookie encryption, including the special persistence cookie, from an HTTP profile, but you did not want to have to enter the default cookie name for each pool where persistence applies (in other words, BIGipServerPool1, BIGipServerPool2, and so on), you could specify a custom Cookie Name in the cookie persistence profile and enter that single name into the HTTP profile's Encrypt Cookies option. Or, you can use the cookie persistence profile to specify encryption options for the special persistence cookie while using the HTTP profile to specify encryption options for any other cookies.
I did a quick test to see what the effect might be if I used both methods together - a cookie persistence profile with a custom Cookie Name (set to MyCookie) and encryption enabled, and an HTTP profile with Encrypt Cookies set to MyCookie and an encryption passphrase, and it "worked" (meaning no errors). But I can't tell if the HTTP profile overrode the cookie persistence profile or if encryption was applied twice, but I do know it is one or the other as the cookie's encrypted value changed when I put the custom HTTP profile on and took it off.
My recommendation is to manage everything to do with persistence cookie encryption from the cookie persistence profile, and use the HTTP profile to encrypt other cookies that the application doesn't already protect from information leakage by itself.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com