OpenSSL has the concept of a BIO to abstract whatever you are reading or writing to. I have used them to read/write to sockets and to files. I have not tried it myself, but I think there is a BIO for shared memory.
http://www.openssl.org/docs/crypto/BIO_s_mem.html You might be able to leverage this. -David > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of William A. Rowe, Jr. > Sent: Monday, February 27, 2006 3:40 PM > To: [email protected] > Subject: Re: Alternative Interface that doesn't use Sockets? > > Apache 2.x mod_ssl (http://httpd.apache.org/) in fact does not use > sockets, > but creates a brigade of buffers to pass up and down the chain. You may > want > to compare your implementation ideas to that implementation. > > Bill > > Michael B Allen wrote: > > Hi, > > > > I have an idea for a new interface. At least from looking at the SSL man > > pages it looks like everything depends heavily on reading and writing > > directly to/from sockets. If the herein suggested interface already > > exists then I'd really like to know more about it. > > > > Anyway, I don't have access to sockets. All socket I/O is handled in > > another process. I only have access to shared memory buffers. > > > > This is what I was thinking about: > > > > typedef struct { > > unsigned char *buf; > > size_t bn; > > ... > > } buf_t; > > > > struct ssl { > > buf_t *intok; > > buf_t *outtok; > > ... > > }; > > > > int > > ssl_write_encode(struct ssl *ssl, buf_t *output) > > { > > if (buf_length(ssl->intok)) > > do_read_handshake_stuff(ssl, ssl->intok); > > if (buf_length(ssl->outtok)) > > do_write_handshake_stuff(ssl, ssl->outtok); > > try_write_encode_payload(output); > > } > > > > The 'buf_t' type just makes thing a little easier on the eyes. The > 'struct > > ssl' type is of course the context that holds all handshake state. The > > 'ssl_write_encode' function would be used to "write" data. So far, > nothing > > new - here's the different part. Ssl_write_encode just takes data from > > 'output' and copies it to 'ssl->outtok' but only after being called a > > few times to let "tokens" go back and fourth. The idea is conceptually > > just like GSSAPI. > > > > To further illustrate how this might be used, consider the following > > example [1]: > > > > int > > test_ssl_write(struct ssl *ssl, int sock, buf_t output) > > { > > FD_SET(sock, &rset_master); > > FD_CLR(sock, &wset_master); > > > > for ( ;; ) { > > rset = rset_master; > > wset = wset_master; > > > > select(&rset, &wset); > > > > /* If there's something to read, then read > > */ > > if (FD_ISSET(sock, &rset)) { > > buf_read(sock, ssl->intok); > > } > > > > ssl_write_encode(ssl, output); > > > > /* If ready to write we must want to write so write it. > > */ > > if (FD_ISSET(sock, &wset)) { > > buf_write(sock, ssl->outtok); > > FD_CLR(sock, &wset_master); > > } > > > > /* If there's something to write, indicate so > > */ > > if (buf_length(ssl->outtok)) { > > FD_SET(sock, &wset_master); > > } > > } > > } > > > > This is a standard select loop. Basically 'ssl_write_encode' is called > > which initially will very likely not even touch 'output'. Instead it > > probably will produce data in 'ssl->outtok' which will cause FD_SET to > > indicate writing is desired. On the next pass 'ssl_write_encode' will be > > called again and presumably do absolutely nothing since it's internal > > state is waiting for an input token which it has not received. But > > the data in outtok will be written, we wait on select, read data into > > 'ssl->intok' and keep going around until the handshake is complete and > > 'output' is actually copied into 'outtok' and transmitted to the remote > > peer. > > > > What do you think? How hard would it be to implement this interface? Any > > ideas? > > > > Thanks, > > Mike > > > > [1] This example defeats the purpose of the interface since it operates > on > > sockets but it's the expected test for my new ssl_write_encode function. > > ______________________________________________________________________ > > OpenSSL Project http://www.openssl.org > > Development Mailing List [email protected] > > Automated List Manager [EMAIL PROTECTED] > > > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [email protected] > Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
