> For example if client connects, you may recv(,,,MSG_PEEK) 5 bytes
> from client socket and check if this bytes are valid SSL2/SSL3/TLS1
> record header (SSL2 and SSL3/TLS1 record headers are different).
> If yes, then you can call SSL_accept() on client socket
> if not, you can read()/write()

This is definitely not legal on Windows and can, at least theoretically,
cause deadlock on any platform. I would strongly urge against this approach.
What if your recv(,,,MSG_PEEK) only returns one byte?

"Polling on a stream socket until a certain number of bytes or a "message"
arrives is bad code. A stream socket, such as TCP, does not preserve message
boundaries because it provides a data stream. As such, the largest message
size an application can ever depend upon is one-byte in length. Code that
uses peeking to wait until a complete "message" arrives might never succeed
on stream-based protocols in Winsock where the data straddles multiple
system buffer boundaries, due to design decisions. The peek operation will
report the number of bytes up until the first buffer boundary. The bytes
remaining in the other boundaries might never be reported, resulting in an
incorrect count of data for code algorithms that depend upon the peek values
to be accurate. Subsequent peek attempts will not reveal the "hidden" data,
which can still be received from the buffers."

http://support.microsoft.com/kb/q192599/
http://support.microsoft.com/kb/q140263/

> but of course better solution is to
> create wrappers witch will hide SSL_read()/read() or recv()
> and SSL_write()/write() or send() with some "virtual socket"

Yeah, that's quite a bit better. The best solution in many cases is to start
out as a normal connection and "promote" to SSL after the client sends some
kind of promotion request. Google for "STARTTLS" to see one implementation.

DS


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to