I did it:
--------------
//
// the connection is already established (with ssl_accept)
//
BIO *internal_bio, *network_bio, *ssl_bio;
int iDataLen;

//
// let's create a new bio pair and the ssl bio
// the internal_bio is not directly used.
//
BIO_new_bio_pair(&internal_bio,0,&network_bio,0);
ssl_bio = BIO_new(BIO_f_ssl());

SSL_set_bio(ssl, internal_bio, internal_bio);
BIO_set_ssl(ssl_bio,ssl,BIO_NOCLOSE);

  
//
// recv'ing
//
iDataLen = recv(sd,szBuffer,sizeof(szBuffer),0);

if(iDataLen == 0 || iDataLen == SOCKET_ERROR)
  break;

//
// decrypting
//
BIO_write(network_bio,szBuffer,iDataLen);
BIO_flush(network_bio);

iDataLen = BIO_ctrl_pending(ssl_bio_write);
BIO_read(ssl_bio_write,szBuffer,iDataLen);

// :-)
if(memcmp(szBuffer,"exit",4) == 0)
  break;
      
//
// crypting the buffer
//
BIO_write(ssl_bio_write,szBuffer,iDataLen);
BIO_flush(ssl_bio_write);

iDataLen = BIO_ctrl_pending(network_bio);
BIO_read(network_bio,szBuffer,iDataLen);

//
// send'ing
//
iDataLen = send(sd, szBuffer,iDataLen,0);


---------

Thank you all,

Strauss

On Mon, 17 Jan 2005 10:36:02 -0700, Trent Harmon
<[EMAIL PROTECTED]> wrote:
> BIO pairs are, by design, completely detached from the socket
> when they are created.  Here's how it works:
> 
>    1. You establish a communication channel (independent of OpenSSL).
>       This could be just another socket.  But, the point is that you
>       establish it without any OpenSSL involvement.
> 
>    2. You create a BIO pair.
> 
>    3. You read data from the socket (the read is done in whatever
>       manner you choose, independant of OpenSSL).  After reading
>       the data, you pass the data into the BIO pair.
> 
>    4. You retrieve data from one-half of the BIO pair (it comes out
>       decrypted).  Then you do whatever you want with the decrypted data.
> 
>    5. You pass "clear" data into one-half of the BIO pair.
> 
>    6. Then, you can retrieve the encrypted data from the other half
>       of the BIO pair.  Once retrieved, you can write it to your socket.
> 
> The point is that the BIO pair takes care of the entire SSL process
> without actually caring about the communications interface (i.e.
> socket).  Note that the BIO pair is manipulating SSL
> records just as they would normally have been done with the socket-style
> OpenSSL interface.
> 
> Have you found the example, ssltest.c, in your OpenSSL distribution?
> If not, it's online:
> http://www.opensource.apple.com/darwinsource/10.3/OpenSSL096-2/openssl/ssl/ssltest.c
> 
> Hopefully that file will make this clearer.
> 
> The book I recommended is a good guide too.  Don't expect to have it
> running in an hour or two.  Give yourself a couple days to prototype
> and understand.
> 
> -trent
> 
> Rodrigo Strauss wrote:
> 
> > I need to follow these steps:
> >
> > - Make the socket connection, keeping the socket in synchronous mode
> > - Call SSL_Accept to initialize the SSL session
> > - Detach the SSL from the socket
> > - Now the socket will be controlled by a network I/O thread (the app
> > already do this and I can't change this behavior). And all data will
> > be sent from another thread.
> > - All the data going to this socket need to be encrypted IN A BUFFER
> > and sent to the thread using a queue (so all the buffer will be sent
> > ordered). The network I/O thread will just read the buffer from the
> > queue and send it. The buffer need to be already encrypted
> >
> > I'm having some problems understanding how bio pairs work. If someone
> > could helpâ
> >
> > Thanks,
> >
> > Strauss
> >
> >
> >
> > On Mon, 17 Jan 2005 07:56:42 -0700, Trent Harmon
> > <[EMAIL PROTECTED]> wrote:
> >
> >>Hi,
> >>
> >>I didn't copy the openssl alias since I don't consider myself
> >>an expert.  You'll likely get other, perhaps better, suggestions
> >>from there.
> >>
> >>But, in the meantime, I think what you're wanting is a "BIO Pair".
> >>This assumes that you're wanting more than just encryption, but that
> >>you're also wanting the SSL negotiation between the two endpoints.
> >>A BIO pair allows you to choose how to send/receive the SSL records.
> >>
> >>You can find an example in .../ssl/ssltest.c.
> >>
> >>It can be a little tricky (especially when you account for flow
> >>control) so be prepared to take some time and lots of testing to
> >>make sure it's working right.
> >>
> >>The book, "Network Security with OpenSSL" by John Viega,
> >>Matt Messier, and Pravir Chandra (ISBN 0-596-00270-X) has a small
> >>section devoted to BIO Pairs on page 94.
> >>
> >>Hope this helps.
> >>
> >>-trent
> >>
> >>P.S. No mem BIO is needed for this.  Just char buffers.
> >>
> >>Rodrigo Strauss wrote:
> >>
> >>
> >>>Hi.
> >>>
> >>>I'm trying (with no success) to detach SSL from a socket, and use it
> >>>to crypt/decrypt using a mem BIO. Instead of using SSL_write, I want
> >>>to write the encrypted data to a mem BIO (or just a buffer) and send
> >>>it by myself (and do the reverse operation on receive). I will do this
> >>>just after the initial negotiation.
> >>>
> >>>All the information will be encrypted, I just need to do the send/recv
> >>>by myself. I need to change an existing application to use SSL. I'll
> >>>need to put the already encrypted buffer in a queue, to be sent by
> >>>another thread. The encryption thread doesn't have control over the
> >>>socket. How can I do this?
> >>>
> >>>Thanks,
> >>>
> >>>Strauss
> >>>______________________________________________________________________
> >>>OpenSSL Project                                 http://www.openssl.org
> >>>User Support Mailing List                    openssl-users@openssl.org
> >>>Automated List Manager                           [EMAIL PROTECTED]
> >>
> >>--
> >>Trent Harmon
> >>[EMAIL PROTECTED]
> >>303.588.6790 (cell)
> >>1.831.303.9797 (fax)
> >>www.redmesasoftware.com
> >>
> 
> --
> Trent Harmon
> [EMAIL PROTECTED]
> 303.588.6790 (cell)
> 1.831.303.9797 (fax)
> www.redmesasoftware.com
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to