Dan Kegel wrote:
>
>
> I'm doing it; right now, I have a single network thread doing all normal
> networking *and* SSL; after I write the load tests that demonstrate
> how woefully inadequate that is :-), I'll split that into two threads:
> one for doing the SSL accept / connect stuff, and one for all other
> networking including bulk SSL. (I have yet other threads for disk I/O.)
> Hope that will suffice, otherwise I get to do a little refactoring, or worse.
>
The problem with that is that a client can renegotiate a session at any
time.
> > Anyway, in principle, I can't see why this would be a big obstacle to
> > using a non-stdio interface - you should just need to create alternative
> > BIOs (or BIO_METHODs, more to the point). Mind you, I've never felt the
> > need to do that nor even use the network-aware BIOs at all myself, so I
> > take what I say with a dose of salt. Have you tried doing this yet?
>
> Where this came up for me was in PEM_read_bio_RSAPrivateKey(BIO *, ...)
> I haven't gotten into the PEM stuff much yet. Maybe there are
> ways of using them without BIO's, but hey, if it's easy to fix
> bss_file.c, maybe I'd do that.
>
Depends where you want the private key. You can use memory or fd BIOs.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
