According to the article below cookie encryption is configured in the HTTP profile Configuring cookie encryption within the HTTP profile (f5.com) To me it would make more sense to perform cookie encrytion in the cookie profile. I do see option in the cookie profile for encryption and passphrase etc. What is the different between the configurations in the cookie and the http profile? Can either be used? What is the best method to configure cookie encryption for several VIPs? If I use the article's method I would have to specify every pool name for each cookie. that would also mean creating a custom HTTP for every VIP I want to add cookie encrytion to (and that would be tedious, I hope there is an easier method).

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 defaultControl 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.

Forum Discussion

ottleydamian

Cirrus

Jul 02, 2021

Solved

Cookie Encryption

According to the article below cookie encryption is configured in the HTTP profile

Configuring cookie encryption within the HTTP profile (f5.com)

To me it would make more sense to perform cookie encrytion in the cookie profile. I do see option in the cookie profile for encryption and passphrase etc.

What is the different between the configurations in the cookie and the http profile?
Can either be used?
What is the best method to configure cookie encryption for several VIPs?

If I use the article's method I would have to specify every pool name for each cookie. that would also mean creating a custom HTTP for every VIP I want to add cookie encrytion to (and that would be tedious, I hope there is an easier method).

BIG-IP

LTM

security

crodriguez
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.

3 Replies

Rob_Stonham
Cirrus
Jul 02, 2021
Hi,

As you mention having to specify every pool name for each cookie I assume that you are wanting to encrypt the persistence cookies.

If each of your VIP's only has one pool, then the solution I used originally was to create one persistence profile of type "Cookie", set a generic cookie name like "persistence_cookie" and set the encryption settings as needed. I then used the same persistence profile across all the VIPs.

You would use the HTTP profile to encrypt any other cookies that you may want to encrypt. Before BIG-IP 11.5.0 it wasn't an option to set cookie encryption on the persistence profile, so you had to use the HTTP profile to encrypt the persistence cookies. (I hope you are running something later than 11.5.0).

Now I use AS3 (https://clouddocs.f5.com/products/extensions/f5-appsvcs-extension/latest/) for creating my Virtual Servers and that makes it easy to create the HTTP profile and cookie persistence profile as part of the declaration to go with the VIP.

Regards

Rob
- ottleydamian
  Cirrus
  Jul 02, 2021
  Thank you very much for your response. Just one clarification. Since I’m running 13.x code you are saying that I CAN just use the cookie profile to encrypt the cookie without using the http profile?
  
  If yes, do I have to set both the ‘Cookie Encryption Use Policy’ and ‘Encryption Passphrase’? Or just the ‘Encryption Passphrase’?
  
  If no, are those two mentioned settings just to encrypt the ‘Default Cookie Name’?
crodriguez
Ret. Employee
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.