[Building Sakai] access/.../WebServlet.setSession question in Sakai 2.4.x

[Casey Dunn]

On Sun, Mar 8, 2009 at 6:03 AM, Stephen Marquard <stephen.marquard at uct.ac.za
> wrote:

> SSL renegotiation was indeed new to me (we lurk and learn!).
>
> So yes, why does the LB send the renegotiated session to a new app server?
> The sessions are supposed to be sticky on the JSESSIONID cookie value. If
> the LB is not using the same type of stickiness as Sakai, then indeed it is
> a problem.
>
> Cheers
> Stephen


I think the theory is that the Session is going to be sent to a new App
server because the client's originating IP could be spoofed, allowing some
bad actor to slide in and hijack the Session _just_ as the SSL handshakes
were being renegotiated.

by going to a new App server the Client has to reauth, and this means a
Hu-Man is involved.

So continuous sessions are infact sticky, as long as they can be trusted.

Trust breaks down when the SSL has to be redone.

If Sakai isn't up to whatever grade of security practices this represents,
then indeed it is a problem. :P LIke we're trusting SSL?

Now this may rarely show up in container login contexts. I dunno. The app I
am describing does not use the container login contexts; it is authing
directly against Sakai's web services. It does a lot of stuff w/out a
Hu-Man. At least it was. It's now trying to detect if it's on a new backend
server and then it tries to re-login on the new box.

btw the afflicted sysadmins are also lurking, and waiting for me to get egg
my  face by daring to raise these question - hmm? I have described the
threat correctly?

that pesky,

casey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20090311/6f2a6c51/attachment.html