[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: OpenSSL SSL_read()/SSL_write()

William Ahern wrote:

I was perusing through libraries/libldap/tls.c deciding whether it was safe
to use non-blocking I/O (i.e. polling the underlying fd) w/ SSL in a client.

	If the underlying BIO is non-blocking, SSL_read() will also return
	when the underlying BIO could not satisfy the needs of SSL_read() to
	continue the operation. In this case a call to SSL_get_error(3) with
	the return value of SSL_read() will yield SSL_ERROR_WANT_READ or
	SSL_ERROR_WANT_WRITE. As at any time a re-negotiation is possible, a
	call to SSL_read() can also cause write operations!

	-- man page SSL_read(3)

In tls.c:sb_tls_read and tls.c:sb_tls_write only one of SSL_ERROR_WANT_READ
or SSL_ERROR_WANT_WRITE is checked after the SSL_read or SSL_write.

Does anybody know if this condition is handled by some other part of the
code? Or alternatively if there is a justified assumption that it could
never happen?

FWIW, tls.c:update_flags seems to miss the boat, too.

In my code I only poll on a read event, since it seems that OpenLDAP does
its writes blocking. However, SSL throws a monkey wrench into this
precarious arrangement.

You seem to be confused about non-blocking I/O. Whether or not a socket/filedescriptor is non-blocking is orthogonal to whether you access it by polling (poll/select) or not. The OpenLDAP library always uses sockets in their default (blocking) mode.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support