apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [PROPOSAL/PATCH] add ssl sockets
Date Tue, 13 Jun 2006 23:36:07 GMT
Garrett Rooney wrote:
> On 6/13/06, david reid <david@jetnet.co.uk> wrote:
> 
>> The attached patch is a first pass at getting some support for using
>> openssl directly for ssl sockets within APR. I've tried to be generic in
>> the basic configure code, but the actaul guts are basically openssl 
>> related.
>>
>> Disclaimer - this is based on some code I had written a while back and
>> never really gotten finished, so this has a lot of it's flaws and
>> unfinished feeling. It does however show the approach I've been taking.
>> There isn't even documentation yet!
>>
>> What's attached isn't anywhere near finished or even heavily tested, but
>> it works as far as it has been tested and at least will (hopefully) spur
>> some discussion about
>>
>>  - whether this is desired
>>  - whether this is the right way to do it (other methods are apparent)

I'm doing some similar work, not for sockets, but to scratch apr's
implementation of hashing, etc from the library.  Your ssl detection looks
great, I'd much rather see this layer in apr-util (and perhaps a apr-helper
lib of it's own) rather than apr core.  It happens to be the same place my
ssl detection code lives.  I'm working on mine for FIPS-140 work.

I'm thinking the most interesting person to ask on this is Brad Nicholes who
implemented a trivial ssl layer using the ssl-enabled sockets.  Obivously
whatever we do, it should be basic enough that he can implement this without
even loading a crypto library.  Likewise Temme works at britestream, and their
and similar hardware can do this with a couple library calls, and use the
tcp/ip api.  All of these could be abstracted through your proposed interface.

In principal, +1!

>> I think it's something we should have and it's something I'll likely
>> persue, but I would like it to be in the main tree of apr-util. I'm not
>> proposing that what's included be submitted directly, but if this is the
>> approach then it'll give a starter for people to hack about.
>>
>> With that background, here is the code... I'm away from tomorrow until
>> Friday, so don't be offended if i don't reply...
> 
> I think this would be great stuff to have around, but if possible I'd
> like to avoid having an entire separate ssl socket type that parallels
> the regular APR socket.  If we could have the ssl functions return a
> socket that knew how to do the SSL parts under the hood, that would be
> great...

In general I would like to avoid overloading too many indirections, and it's
certainly too complex to implement in one generic apr_socket_create.

But for read/write/poll, I'd like to see how painlessly we could implement
this.

Moreso, I'd like to see if we can ensure there is only one apr read/write/poll
sort of operation across all apr entities.  Even if it needs to be something
like apr_generic_read() (fugly name, sue me).

This work is on the right track, that's for sure.  Let me look at blending our
two ssl detection stubs together (damn wish I was paying attention and could
have spared you reimplementing, sorry :(  )

Bill

Mime
View raw message