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 openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
