On Fri, Jan 16, 2004, Joseph Bruni wrote: > > On Jan 16, 2004, at 5:57 PM, Dr. Stephen Henson wrote: > > >On Fri, Jan 16, 2004, Joseph Bruni wrote: > > > >>After reading the man page for SSL_CTX_set_mode, I have to ask, > >>what happens if you set AUTO_RETRY with a non-blocking socket? > >> > > > >The AUTO_RETRY flag disables a case where the SSL/TLS code would > >signal a retry even > >though the underlying transport did not during a session > >renegotiation. This is > >there to support some applications which brokenly use select() and > >blocking I/O. > > > > Now you have me curious: What would be a broken use of select and > blocking I/O? I use select before a call to SSL_read in order to > facilitate a timeout. Is this wrong (or broken)? (If I receive one of > the "WANT" errors, I just restart the I/O however.) My program makes > the assumption that if it hears nothing on the read side of the socket > during a period of time, that something is wrong. > > Currently, I don't like the way my I/O loop is working so I'm probably > going to switch to non-blocking anyway.
Yes thats one broken way. The usual way of using select() with normal I/O is to select() on the appropriate condition then call read(), write() or whatever on the socket. Some applications (including s_client!) do the same. To give an example, if select() indicates data can be read then calling SSL_read() may not immediately have any data because a complete record hasn't been read. However under normal circumstances it will get some data when a whole record is received. That could mean SSL_read() blocks a while but it will get data. If an error condition arises the SSL_read() would return an error. Now consider the case of a renegotiated session. The other side might send appropriate messages which would indicate a session needs to be renegotiated. Calling select() might indicate that data is available but it isn't application data. When the renegotiation completes there isn't necessarily going to be any data available for SSL_read() at all. As a result SSL_read() could block indefinitely. This situation is avoided by signalling a retry after the renegotiation is complete and the new session established. Then the application can call select() again and retry the read. This is a work around because such application behaviour is just plain broken because of the possiblity of SSL_read() (and SSL_write() ) blocking on partial records indefinitely. Presumably the application author's use of select() was to avoid blocking: they will most of the time but under rare circumstances (possibly maliciously) blocking can occur. The only way to ensure that indefinite blocking is avoided is to use non blocking I/O. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
