Forum Discussion
CirrostratusEncrypting a cookie with HTTP::cookie encrypt and encrypting with an HTTP Profile
Does anyone know if it possible to use HTTP::cookie encrypt when generating an HTTP response generated from APM Event ACCESS_POLICY_COMPLETED and then have this cookie decrypted with the normal HTTP profile decryption process when not using APM?
For performance reasons, I would rather use the HTTP Profile for decryption as opposed to custom code within my iRule.
I have tried setting the encryption phrase in the HTTP profile to be the same as used on the HTTP::cookie encrypt command.
Thanks.
3 Replies
- Kevin_Stewart
Employee
I'm going to go out on a limb here and say, based on testing, that cookies encrypted with the HTTP profile cookie encryption cannot be decrypted with the HTTP::cookie decrypt command (and vice versa), nor would you need to do this. The HTTP cookie encryption option performs both encryption and decryption on cookies that pass through the proxy.
Further, I attempted to encrypt the MRHSession cookie with the HTTP profile encryption option and that completely broke the access session. If you're not trying to encrypt the access session cookies, then simply applying the HTTP profile cookie encryption option should both encrypt and decrypt any other (designated) cookies. Now, if you wanted to encrypt the MRHSession access session cookie, that could actually be done with layered virtuals. Put an LTM VIP in front of your APM VIP and apply the HTTP profile cookie encryption there.
when CLIENT_ACCEPTED { virtual [internal VIP name] } - Kevin_Stewart
Well, can you be more specific about "cookies inserted or generated from ACCESS_POLICY_COMPLETED"? What cookies are you trying to send in this event and how? The access session cookies aren't generated in this event, and this is not usually the event that you'd want to try to send cookies.
- Kevin_Stewart
Well, at the very least I'd never send the user's password in a cookie, encrypted or not. Otherwise you already have the access session cookie so you could store the password (encrypted) in the session table. Or you could generate a random GUID, make an LTM session table entry with the password, tied to this GUID, and then send that value as a temporary cookie. And if it's a different URL, make that cookie domain-scoped and short-lived.
