> Adam Grossman wrote: > >> One last questions, and i am done bugging you about this... >> >> These are the steps i am taking: >> >> SSL_set_fd(ssl_data->ssl_ssl, sock_fd); >> sslbio=SSL_get_rbio(ssl_data->ssl_ssl); >> >> internalBIO=BIO_new(BIO_s_bio()); >> BIO_set_write_buf_size(internalBIO, 1024); >> >> BIO_make_bio_pair(sslbio,internalBIO); >> >> size=read(sock_fd,buffer,128); // returns as read 128 >> size=BIO_write(sslbio,buffer,size); // returns as written 128 >> >> SSL_accept(ssl_data->ssl_ssl); >> >> and then the accept always fails. >> >> >> i thought this was straight forward, but i am very wrong (or very >> thick...) > > You two are talking about two very different things. Victor Duchovni is > talking about separating the SSL engine from the socket, so you can put > anything you want between the two. You are talking about "peeking" into > the SSL data stream so you can decide whether to implement SSL or not. > He's telling you the supported way to do what you want and you are trying > to hack it in. > > What does the rest of your architecture look like? Is your application > multi-threaded? Does it handle a larger number of SSL connections? Is it > intended to be portable? Because if your answers are yes, yes, and yes, > (or no, yes and yes) you are approaching this completely the wrong way and > should follow Victor Duchovni's approach. > > DS > > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org >
thanks for the patience with me. i literally started 5 days ago learning openssl while working on this project which has a very short timeline. the application is not multithreaded, has to handle a lot of connections and does not need to be portable. i was asked to take an existing server, and have it do the SSL handling, instead of another backend process. it is a very specific architecture for a very specific purpose. The problem is that the clients have been hacked to add some information within the first packet sent over. and i, unfortunately, can't change that. so i need to be able to read in the raw first 128 bits, get some info out of that, and the have the SSL connection go just as normal, never needing to intervene again. off the top of my head (i do not access to the code right now), it places a few bits of info where it claims the first cipher is,but getting the cipher list does not show anything useful (i think bits 40 and 41 for SSLv2 for instance) everything i have written so far has worked perfectly, until i ran into this snag. thank you so, so, so much and if you any of you are in the philly area, i owe you a beer :) -=- adam ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
