Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
From: Geoff Thorpe <geoff@geoffthorpe.net>
To: dev@httpd.apache.org
Subject: Re: Apache with Security Processor - Interesting
Date: Thu, 21 Oct 2004 15:02:33 -0400
User-Agent: KMail/1.7
References: <a9283a2004101316045826795f@mail.gmail.com>
 <200410202010.53233.geoff@geoffthorpe.net>
 <54f1458d04102110057de11284@mail.gmail.com>
In-Reply-To: <54f1458d04102110057de11284@mail.gmail.com>
Sender: Geoff Thorpe <geoff@geoffthorpe.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200410211502.33629.geoff@geoffthorpe.net>

On October 21, 2004 01:05 pm, Madhusudan Mathihalli wrote:
> On Wed, 20 Oct 2004 20:10:53 -0400, Geoff Thorpe <geoff@geoffthorpe.net> 
wrote:
> > Did the control-command support ever make it into a cvs-worthy form?
>
> Nope - I don't believe it is in the CVS. Can you re-send the patch ?

Um, all I have is an old version for mod_ssl (apache 1.3) on my website 
(in the "crypto" page) - it adds the SSLCryptoDeviceCtrl directive. IIRC, 
one of the Bill's on this list ported this to 2.* form, you may be able 
to find it in the archives I guess (I'm at work and so not able to trawl 
for this right now). Note, I wasn't terribly pleased with how I 
implemented it, so I don't pretend to suggest this is the Right Way(tm).

> > That's a far more general way to squash this issue.
>
> Well.. I'm not sure of that - it'll probably be more clear after
> seeing your patch. AFAICT, we have so some how force Apache to load
> the dynamic engine - and that's pretty much what my patch does.

Yes, and in your implementation you're doing this by issuing various 
control-commands exposed by the "dynamic" engine to achieve it. This 
magic may be a suitable transparent behaviour to use when the specified 
engine can't be initialised directly, but it's still limited to whatever 
logic you hard-code into the existing SSLCryptoDevice directive. Any 
other commands supported by the "dynamic" engine (let alone any supported 
by the targetted engine once it's loaded) would be inaccessible unless 
someone goes in and adds further C logic. Eg. if an engine requires 
configuration/authorisation, it can expose those details as 
control-commands and as long as there's a mechanism to pass arbitrary 
commands from the configuration file through, then Apache wouldn't need 
to be any the wiser. Eg. the existing autoloading magic, plus additional 
device-specific setup/control, could be achieved with;

SSLCryptoDevice      dynamic
SSLCryptoDeviceCtrl  SO_PATH:/lib/.../foobar.so
SSLCryptoDeviceCtrl  LOAD
[... the "dynamic" engine is now replaced by the loaded engine...]
SSLCryptoDeviceCtrl  FOOBAR_LOGFILE:[...]
SSLCryptoDeviceCtrl  FOOBAR_AUTH:[...]
...
[... appending 'post' executes commands after ENGINE_init() ...]
SSLCryptoDeviceCtrl  FOOBAR_LOCK    post
...

Without something like this, the functionality is limited to whatever is 
explicitly coded into apache, which I think is a little limiting. Also 
useful will be some alterations that allow HSM keys to be used - I can 
help with that if you like, but it'll definitely need control-command 
support first.

NB: Another way forward is to try and hook into Steve Henson's revisions 
to the configuration code. This essentially offloads all of this sort of 
stuff to an openssl-specific configuration file that is "executed" at the 
appropriate moment(s). We'd need to get Steve involved in that discussion 
though if you're interested (there are potential pros and cons to this).

Cheers,
Geoff

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