On Sun, May 07, 2006 at 01:15:49AM +0200, Dr. Stephen Henson wrote:
> > > 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...
> >
>
> Well looking at this more closely it *is* just when compression is enabled
> that this happens. The code assumes the first packet is of even length so that
> if an odd length packet is found it can assume the bug is present. When
> compression is enabled this assumption is no longer true.
Excellent, so perhaps this issue will be solved in 0.9.8c...
> Since the work around has existed since the SSLeay days I'd say that it is
> very unlikely that a buggy implementation will also support compression. So
> I'd say the simplest solution is to disable the check if compression is
> negotiated.
>
I'll gladly test any snapshot that addresses this issue. Is there any
way to determine at run-time whether the OpenSSL library is a 0.9.8[ab]
release with zlib enabled?
For Postfix 2.3 (and perhaps even a 2.2 patch at some point) I would like
to use (SSL_OP_ALL & ~SSL_OP_TLS_BLOCK_PADDING_BUG) provided
OPENSSL_VERSION_NUMBER >= 0x0090800fL &&
OPENSSL_VERSION_NUMBER <= 0x0090802fL
but it would be nice to avoid this when zlib support is not compiled in.
Is there a run-time test for that?
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
