[EMAIL PROTECTED] wrote:
>
> 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.
Well, quite. I meant sessions that your HTTP-utilising application
creates.
> 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 understand the idea. My point is mostly that the lifetime you would
like for this "user session" has completely different requirements from
the SSL session.
> 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.
Right. But the main point is that there are at least three really
obvious ways to do this properly, so why try to bend SSL session IDs to
a purpose they don't really fit?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
