Re: mod_ssl to-do items

[Justin Erenkrantz <ju...@erenkrantz.com>]

--On Thursday, March 6, 2003 12:42 PM -0500 Geoff Thorpe 
<ge...@geoffthorpe.net> wrote:

> linking apache. I'm wondering if the above problem is a consequence of
> us explicitly setting linker syntax and not letting autotools do their
> job properly? Anyway, the patch is there if someone wants to see if it
> helps with this issue as well.

I think the issue is that mod_ssl as a DSO has to have a special set of linker 
flags just for *it* rather than relying on the original set of libraries (i.e. 
pull in OpenSSL).  The proper solution to this would be to allow a module to 
explicitly have its own compiler, linker, etc. flags.  (mod_deflate as a DSO 
could benefit if only it linked against libz.)

It's a slightly more generic problem than just mod_ssl.

>>     * session cache store should be pluggable
>
> I'd like to speak with the person who's behind this, as I'm waiting for

(Pardon me while I go off on a tangent...)

Note that there really isn't a single person who is responsible for mod_ssl. 
The only person who may claim that is Ralf and he hasn't been involved for 
years.  All of us on this list are implicitly responsible.  Some people are 
more involved than others though - Madhu and DougM have been beneficial to 
keeping it running though (among others that I have forgotten right now - 
sorry!) - but the point of adding mod_ssl to our tree was so that it could be 
group-maintained rather than a specific individual.  So, I wouldn't go look 
for a specific person to talk to.  Whomever that person would be should be 
reading this list.  Just start having a conversation about what you'd like to 
see happen on this list and people will magically start to chime in.  And, 
keep submitting patches about what you'd like to see fixed - it's the surefire 
way of getting our attention.  (And, simply repost if you don't hear anything 
in a week...)

>>     * the shmcb code should just align its memory segment rather than
>>       jumping through all the "safe" memcpy and memset hoops
>
> I wrote shmcb and I don't think the person who wrote this quite
> understands why this "jumping through hoops" is done. Trying to align
> all the relevant data will cost more than just a few wasted bytes of
> storage, and I respectfully suggest that the "safe" accessors (which
> aren't speed-critical) would be easier to maintain. Again, I'm available
> to bash these ideas out if anyone's interested.

It's probably under the idea that we'd save a few cycles and make the code 
more understandable if we relied upon alignment.  In fact, I believe the 
second argument is the more compelling one.  I find the safe calls a 
tremendous difficulty in understanding the shmcb code (which, AIUI, is broken 
right now).  -- justin

Re: mod_ssl to-do items

[Geoff Thorpe <ge...@geoffthorpe.net>]

Hi,

* John K. Sterling (john@sterls.com) wrote:
> 
> As justin said, this is something that has been randomly discussed from
> time to time for many years now.  MANY people see the need for this for
> obvious reasons.
> 
> As for the STATUS file entry, the concrete meaning (from a high level):
> 1) create a pluggable session storage interface (ala perl's tied hash)
> 2) expose it to apache modules
> 3) implement some standard back-ends
> 4) convert the ssl code to use it for session storage.

Yup, makes sense. I'm still wondering if the right way to do this is in
openssl though, because it's a generic problem for SSL/TLS rather than
anything specific to HTTPS (and in theory there is no reason why Apache
shouldn't be able to share a session cache with other SSL/TLS software).

> I have heard of some pluggable c session storage code out there, but to
> add another external project dependency would be lame.  perhaps it could
> get added to apr-util... otherwise mod_ssl would have to compile it in locally.

I don't know if this is/was distcache, but distcache is about half my
interest in this subject (the other half being openssl). I'm waiting to
finish the openssl configuration stuff in http-2.0 before trying to
submit a patch for distcache support - so if modularising might affect
this I could look at it at the same time and perhaps save myself some
effort later on. I think however that the current caching interface is
not a great base to be generalising from (which to be fair is
essentially inherited from the same limiting interface in OpenSSL that
hasn't been substantially touched since SSLeay days).

Is anyone working on this already or ready to do so now? If so please
make contact so we can avoid duplication of effort. If not, I'll start
giving it some thought, although I'll probably ask that I be allowed to
sort out and contribute my distcache hooks into the existing modules/ssl
first. I need to clear a few things off my TODO list before embarking on
investigations of this sort.

One of the issues about modularising session caching is that it would
make a lot of sense to allow caches to be "stacked". This already
happens in some sense with openssl managing a per-process stack and
apache's SSLSessionCache allowing an application cache to be plugged in
on top. That limiting interface I spoke of already causes problems at
this point, because there's no "has_session" type of hook that allows
the inner cache to quickly check with the external cache in case a
locally-cached session has been *cancelled* by the external cache. This
created a vulnerability that was fixed in Apache-2 when I raised the
subject on the modssl-users list, but as far as I know is still lurking
unchanged in mod_ssl/apache-1.3.  The fix of course has no choice but to
shut off the internal cache completely and use the external cache
directly. So this same interface is not going to lead to any clean way
to layer caching mechanisms.

(This is stuff I've been dealing with in distcache BTW, but that's
another spiel for another day).

Thanks for getting back to me about this.

Cheers,
Geoff

-- 
Geoff Thorpe
geoff@geoffthorpe.net
http://www.geoffthorpe.net/

Re: mod_ssl to-do items

["John K. Sterling" <jo...@sterls.com>]

>-- Original Message --
>From: Geoff Thorpe <ge...@geoffthorpe.net>
>Nonetheless, I'd like to know who the person(s) are that are behind the
>statement in the STATUS file so that I can find out what it is (exactly)
>that they mean and what (if any) history there is to the idea. "session
>cache store should be pluggable" has an encouraging sound to it, but is
>somewhat unburdened by any concrete meaning that I can see. :-)

As justin said, this is something that has been randomly discussed from
time to time for many years now.  MANY people see the need for this for
obvious reasons.

As for the STATUS file entry, the concrete meaning (from a high level):
1) create a pluggable session storage interface (ala perl's tied hash)
2) expose it to apache modules
3) implement some standard back-ends
4) convert the ssl code to use it for session storage.

I have heard of some pluggable c session storage code out there, but to
add another external project dependency would be lame.  perhaps it could
get added to apr-util... otherwise mod_ssl would have to compile it in locally.

that's what i remember - 

sterling

Re: mod_ssl to-do items

[Geoff Thorpe <ge...@geoffthorpe.net>]

Hi (again :-),

* Justin Erenkrantz (justin@erenkrantz.com) wrote:
> --On Thursday, March 6, 2003 12:42 PM -0500 Geoff Thorpe 
> <ge...@geoffthorpe.net> wrote:

[snip]

> >>    * session cache store should be pluggable
> >
> >I'd like to speak with the person who's behind this, as I'm waiting for
> 
> (Pardon me while I go off on a tangent...)
> 
> Note that there really isn't a single person who is responsible for 
> mod_ssl. The only person who may claim that is Ralf and he hasn't been 
> involved for years.  All of us on this list are implicitly responsible.  
> Some people are more involved than others though - Madhu and DougM have 
> been beneficial to keeping it running though (among others that I have 
> forgotten right now - sorry!) - but the point of adding mod_ssl to our tree 
> was so that it could be group-maintained rather than a specific individual. 
> So, I wouldn't go look for a specific person to talk to.  Whomever that 
> person would be should be reading this list.  Just start having a 
> conversation about what you'd like to see happen on this list and people 
> will magically start to chime in.  And, keep submitting patches about what 
> you'd like to see fixed - it's the surefire way of getting our attention.  
> (And, simply repost if you don't hear anything in a week...)

Thanks for the tangent, it's good to know what the conventional wisdom
is w.r.t. code management (it seems contributing to apache2's mod_ssl
might be less troubled by long periods of silence than has been the case
with apache1.3 mod_ssl sometimes :-).

Nonetheless, I'd like to know who the person(s) are that are behind the
statement in the STATUS file so that I can find out what it is (exactly)
that they mean and what (if any) history there is to the idea. "session
cache store should be pluggable" has an encouraging sound to it, but is
somewhat unburdened by any concrete meaning that I can see. :-)

> >>    * the shmcb code should just align its memory segment rather than
> >>      jumping through all the "safe" memcpy and memset hoops
> >
> >I wrote shmcb and I don't think the person who wrote this quite
> >understands why this "jumping through hoops" is done. Trying to align
> >all the relevant data will cost more than just a few wasted bytes of
> >storage, and I respectfully suggest that the "safe" accessors (which
> >aren't speed-critical) would be easier to maintain. Again, I'm available
> >to bash these ideas out if anyone's interested.
> 
> It's probably under the idea that we'd save a few cycles and make the code 
> more understandable if we relied upon alignment.  In fact, I believe the 
> second argument is the more compelling one.  I find the safe calls a 
> tremendous difficulty in understanding the shmcb code (which, AIUI, is 
> broken right now).  -- justin

Broken? How so?

As for the safe calls - if they're a difficulty then they should be
clarified because the principle is very simple.

However to be more constructive than that; they can probably be done
away with completely without losing the design if I get approval to
restructure ssl_scache_shmcb.c a bit. Namely, the various structures
used in the layout/geometry could just be memcpy()d to/from the relevant
locations rather than having references to them in which individual data
elements are "safe"ly accessed one-by-one.

The geometry/layout shmcb places on the shared-memory segment was
reasonably-well thought out, but the code that implements it is more
"organic" - it grew into its current shape as I attempted to prototype
the storage model. A little bit of rewriting and rewiring would (I
suspect) greatly simplify things and I'm reasonably confident they would
obviate the need for the "safe" functions - the alignment correction
would be implicit by memcpy()ing the larger non-primitive structures
between non-aligned shared memory and aligned local variables. This
would slightly increase the amount of memcpy() activity (which was the
naive reason that the "safe" approach was used to begin with) but it may
just as likely be an improvement if a couple of bigger memcpy()s turn
out faster than lots of little ones. Certainly this wouldn't affect the
handling of the raw session data itself, and so I doubt any amount of
profiling would show the slightest difference one way or the other.

Anyway, I can put that on my TODO list if there are people who'd
accommodate it by reviewing and helping me test.

Cheers,
Geoff

-- 
Geoff Thorpe
geoff@geoffthorpe.net
http://www.geoffthorpe.net/