On Sat, Jan 16, 2010, adam.gross...@devitron.com wrote: > > 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 :)
Not had time to read the full details yet but I wonder if it is possible to do this another way. BIO pairs will certainly work well and you've then get a lot of control over the whole process. An alternative which *may* work would be to read the first x bytes in, decide if that is SSL/TLS there manually by inspecting a few bytes. If so write that first bit to a memory BIO attach the SSL connection to that BIO for read and the socket for write. Once all the data has been read from the memory BIO you should get a WANT_READ condition which indicates it is empty. Then switch over the read side to the socket and you then proceed as normal. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
