"Ralf S. Engelschall" <[EMAIL PROTECTED]> writes:
> On Mon, Mar 29, 1999, [EMAIL PROTECTED] wrote:
>
[snip]
> > Unless there is some standard way to come
> > up with session id's then there is the possiblity that modules could use
> > the same session id within the same pool which would be bad.
>
> I don't understand your problem. I think you image the shared memory pool
> incorrectly. A shared memory pool in Apache is just a shared memory segment
> with a malloc(3)-style API on top of it which allocates chunks inside this
> segment. The session cache is then nothing more than a hash-table which
> allocates it's pieces inside this shared memory segment with the
> malloc(3)-style API.
>
> So why should be there a conflict between modules? The hash table is private
> to mod_ssl even when the whole shared memory segment in which it stays is
> shared by all modules. Don't think that a shared memory segment is treated as
> a single hash table or cache structure. The shared memory segment is the
> underlaying object for a malloc-library the same way the malloc(3)-library
> allocates from the heap.
Indeed. My misunderstanding. I was _still_ envisioning a much higher-level
"session layer" that Apache would provide, rather than just a shared memory
pool from which modules could then create their own "sessions".
>
> > Which leads me
> > to beleive that it would be nice to have a "tighter integration" between
> > other modules, "the session cache" and the SSL session id. Since there is a
> > good amount of assurance that this SSL session id cannot be spoofed unlike
> > other methods based on cookies or some such thing. Recent events not with
> > standing.
>
> Sorry, I still don't understand the point here, too. Why do you want that
> other modules should be able to access the session ids in the session cache?
So that other modules may use the SSL session id as the key in their hash
tables.
Let's say I want to write a module that authenticates users based on a
challenge/response scheme like X9.9. In this scheme, roughly, a server
calculates a random number and sends this random number to a user. The user
DES encrypts this random number and sends the DES encrypted value back to
the server along with a user id. The server then finds the key that is
associated with this user id. The server then DES encrypts the random
number with this key. If the DES encrypted value that the server calculates
is the same as the DES encrypted value that the user sends, then the user
is successfully authenticated based on the fact that the user and server
must share same key (secret).
The trick is to keep tract of users who have already successfully
authenticated themselves. You could use cookies, but these are highly
spoofable. Or you could do something like require that SSL be used so you
could associate the user id with the SSL session id somehow. This is the
approach I'd like to be able to take.
Is this more clear?
-Tom
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
