Ben Laurie <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
> >
> > The idea behind this is to make the ssl session id available so that other
> > modules may use the ssl session id as a `key' into their own session table.
>
> This really isn't a good idea. The most obvious reason is that there is
> a conflict between the lifetime requirements for SSL sessions and HTTP
> sessions. Another is that clients are not required to reuse SSL
> sessions, and may time them out arbitrarily.
Not sure I understand your first point. Do you mean on a per-packet basis?
The way I see it, there is no `session' within HTTP. No user session that
is. My idea is to have the user authenticate, and then bind the user id to
the ssl session id. Next time around, I'll see that I have an user id
associated with the ssl session id and not bother with the authentication
mumbo jumbo. We're not doing Basic or Digest authentication. We have a
forms based scheme that can back-end against just about anything, RADIUS
challenge-response even.
I see your second point. At worst this would mean the user would have to
re-authenticate. And the old, non-reused, session would just timeout.
-Tom
--
Tom Vaughan <tvaughan at aventail dot com>
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
