Re: Cookie Persistence

Hi Ravi,

Not sure which product you might be referring too, but it my experience,
encrypting cookies on the ADC has almost negligible performance (sure,
non-zero...) performance impact but provides an excellent focal point to not
only ensure maximum application performance, and also consistent security -
across a heterogeneous application environment.

As Hamish point out, in theory you could/ should do it all at the individual
servers, however (again in my experience over 10 years working in ADC
environments) few organisations have the rigour or discipline across their
multiple application towers to ensure consistent and robust security at the
application level. And most ADCs have horsepower to burn...

I'm sure that some might argue that there are exceptions to the rule, and
they'd be right. However, on balance, the ADC is the simplest, most generic,
and consistent place to enforce a number of security and application
optimisation functions including cookie encryption.

Cheers,

Andrew

-----Original Message-----
From: Ravi Kumar [mailto:[email protected]] 
Sent: Thursday, 2 July 2009 3:26 PM
To: Hamish Marson
Cc: Load Balancing Mailing List; Kenneth Salchow; [email protected];
[email protected]
Subject: Re: [load balancing] Cookie Persistance

I agree that encrypting cookies consumes processing time for the ADCs and
is a performance impact.
At the same time, it prevents from smart hackers who has the capability to
use that little information to exploit the servers.

Thanks,
-Ravi.


> Quoting Kenneth Salchow <[email protected]>:
>
>> Content-Type: text/plain;
>> 	charset="iso-8859-1"
>> Content-Transfer-Encoding: quoted-printable
>>
>> BTW--you might also want to see if you can apply encryption to those
>> cookies
>> at the ADC--whether generated by the ADC or the server.  Especially if
>> you're using something like JSessionID from the server.  It's a fairly
>> simple thing that can dramatically increase your overall security
>> posture.
>>
>
> I have to jump in here... Encrypted cookies are (Or should be) a
> complete waste of time.
>
> If you follow the guidelines of basic best practice and security, any
> cookie content SHOULD be an opaque key. With no actual data in it. Any
> cookies you set in an HTTPS session should also be set as a secure
> cookie so it is never presented across an http session (To prevent
> cookie stealing).
>
> Good security practices start with a healthy dose of paranoia. If
> there's no data in a cookie there's only the 'key' aspect of it to
> take care of (i.e. it doesn't matter if someone steals an opaque
> session id a week later. The session has expired therefore the session
> data will no longer be on the server. The data is only vulnerable
> until it expires. But a session cookie that includes data is
> vulnerable forever.
>
>
>
> regards
>    Hamish.
>
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
>



_______________________________________________
lb-l mailing list
[email protected]
http://vegan.net/mailman/listinfo/lb-l
Searchable Archive: http://vegan.net/lb/archive
http://lbdigest.com Load Balancing Digest
http://lbwiki.com Load Balancing Wiki