Cookie Encryption Issue

Prince,

When you say:

Packet capture on F5 shows that sometimes cookie is encrypted and sometimes it is not.

It brings up a couple questions.

How was the capture taken?

Is this a new configuration? Or has it been in place for some time?

Hi Jeremy,

Traffic was captured using simple tcpdump command:

tcpdump -vvv -s0 -nni 0.0:nnn host VS_IP or host SERVER_IP

No encryption decryption has been performed.

Configuration has been there for a while. If i say it right, the issue was noticed recently.

to confirm Prince, the cookie will be encrypted between the client and f5 and then decrypted between f5 and server, is that what you are seeing? Have you tried using a tool like httpwatch, httpfox or fiddler on the client(s) to confirm that the cookie is encrypted at the client?

Nathan, i am talking about the data flow between F5 and backend server. In that data, i see sometimes the cookies are encrypted and at times it is not.

So wondering is this so ? Not checked on the client, but my first concern is when cookie encryption is set to required, shouldnt it always be encrypted :

ltm persistence cookie /Common/Persist_192.168.1.1_443 
{ app-service none 
**cookie-encryption required** 
cookie-encryption-passphrase $M$O0$PU5nvTKYL2GUTJInH7ZvSw== 
defaults-from /Common/cookie 
method insert 
timeout 180 
}

it's encrypted from f5 to client, but the f5 will decrypt the cookie to ensure it will send to the persisted backend pool member. i wouldn't think it would re-encrypt as the server would not know how to decrypt, or even need to.

I did some tests in my lab, because my view is different from previous posts.

The cookie used for persistence is only relevant to the F5, so the backend server does not care about the content, as it will not use the content in the backend application logic.

My view is that the cookie encryption should work in both client and server side. So, cookie should appear encrypted in both sides.

Here is the solution that talks about that:

https://support.f5.com/csp/article/K23254150

However, it does not says if the F5 will decrypt the cookie before sending to the pool member.

Here are the results from the tests I did:

45  44.523717   10.0.0.30   10.0.0.100  HTTP    606 IN  s1/tmm5 : GET / HTTP/1.1 
Cookie: Chocolate=Price%3D1pound; Coconut=Price%3D2pounds; BIGipServerpool_http=!dNjF6oF/ywGMOg71+Oqa3TmDUFddsgwlcA7uN45/F5yOZR1j3LEabgFgCOVEthBD+adp7IQw1b/CRw==\r\n

50  44.525189   10.0.0.30   172.16.0.12 HTTP    545 OUT s1/tmm5 : GET / HTTP/1.1 
Cookie: Chocolate=Price%3D1pound; Coconut=Price%3D2pounds; BIGipServerpool_http=201330860.20480.0000\r\n

74  45.888524   10.0.0.30   10.0.0.100  HTTP    606 IN  s1/tmm5 : GET / HTTP/1.1 
Cookie: Chocolate=Price%3D1pound; Coconut=Price%3D2pounds; BIGipServerpool_http=!dNjF6oF/ywGMOg71+Oqa3TmDUFddsgwlcA7uN45/F5yOZR1j3LEabgFgCOVEthBD+adp7IQw1b/CRw==\r\n

75  45.888582   10.0.0.30   172.16.0.12 HTTP    606 OUT s1/tmm5 : GET / HTTP/1.1 
Cookie: Chocolate=Price%3D1pound; Coconut=Price%3D2pounds; BIGipServerpool_http=!dNjF6oF/ywGMOg71+Oqa3TmDUFddsgwlcA7uN45/F5yOZR1j3LEabgFgCOVEthBD+adp7IQw1b/CRw==\r\n

So, first request is decrypted before is sent to the pool member. However, second and next requests, are not decrypted. This was tested in version 13.0.0.

There is a request for favico.ico, this is the request the browser sends to get the site image. This is triggered right after the response for the first request is received, and does not include any cookies (neither the ones the backend server sets, neither the persistence). I guess is normal, as the first response is been processed.

F5 will only send the set cookie in the first response, so this is the only opportunity to send it decrypted. On the other hand, every request after the first one will have the cookie, so more opportunities to decrypt before send to the pool member.

Concluding, it should always encrypt or decrypt. If is doing sometimes, does not seems correct. As this is happening in your network, I guess you have a valid problem and should open a ticket with F5 support to check this.