On Sat, May 06, 2006, Victor Duchovni wrote: > On Sat, May 06, 2006 at 10:58:57PM +0200, Dr. Stephen Henson wrote: > > So I take it that the recommendation is to use: > > (SSL_OP_ALL & ~SSL_OP_TLS_BLOCK_PADDING_BUG) >
Yes, for now at least. > > No one is sure if the bug it works around exists any more. There could be > > two > > possibilities... > > > > 1. The workaround has been around since the SSLeay days so it only applies > > to > > ancient and obsolete software which no one uses any more. > > > > 2. The workaround has silently fixed problems since the SSLeay days so no > > one > > has bothered to fix it. > > Should work-arounds that cause FPs with new features still be included > in SSL_OP_ALL (which is documented to be "safe" to use for maximum > interoperability)? It seems to me that either zlib compression even if > supported by the library should not be enabled in applications that don't > explicitly request it, or that SSL_OP_ALL should not be incompatible > with compression. > > Having both SSL_OP_ALL and zlib enabled by default (when compiled-in) > is currently a disaster. What is the right solution? Telling distributions > to not enable zlib? Telling application writers to no longer use SSL_OP_ALL? > Just disabling the block padding bug work-around? Something else? > > Can the work-around be made compatible with zlib? > It isn't just zlib AFAICS, it may be triggered in other cases too. Well at this stage it isn't clear what the correct solution is, it needs a bit of further study... If there are few (or ideally no) implementations that this workaround is needed for then the code can simply be removed from OpenSSL. The patch in PR#1204 as I understand it turns a common false positive in correct implementations into a much rarer false negative on incorrect implementations so if nothing better can be thought of that may be a usable compromise. However if the bug is widespread that may result in an increase in failed connections, possibly after the intial handshake I'd guess with "bad record mac" errors. I'm not sure if there is any additional redundancy in the message formats that would allow the bug to be detected consistently or if we can devise a cleverer test. 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 openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
