0.9.8b + zlib + "-bugs"?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

0.9.8b + zlib + "-bugs"?

Victor Duchovni

With 0.9.8a, and now also 0.9.8b, building with zlib and running with
the usual bug workarounds ("-bugs" option) results in code that does
not appear to handle session renegotiation correctly. Is compression
incompatible with "-bugs", or is there an implementation issue?

Some vendor distribution of OpenSSL enable all the bells and whistles
(specifically at least zlib) and the resulting code may exhibit problems
when connections are resumed and (SSL_OP_ALL) ("-bugs") is set.

The documentation says:

   It is usually safe to use SSL_OP_ALL to enable the bug workaround
   options if compatibility with somewhat broken implementations is
   desired.

Is this still the case? Should applications (e.g. MTAs) that want
maximum interoperability still set the SSL_OP_ALL options?

============= s_server and s_client without "-bugs" ==============

Interesting that the initial session is uncompressed, but the resumed
session is...

$ ./apps/openssl s_client -cipher ADH -reconnect -connect localhost:12345
CONNECTED(00000003)
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 291 bytes and written 198 bytes
---
New, TLSv1/SSLv3, Cipher is ADH-AES256-SHA
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ADH-AES256-SHA
    Session-ID: 7EA1BD96E349CB6C0A9A289B4B5BE6BE0B2C66B02C1B769C3A2B75A8F7BAF90C
    Session-ID-ctx:
    Master-Key: 5D937FDECCFB1419333FF309753F4BB2F2AA016FAD1D2918DA50FEA24CE0EE9F939290A7942932F56054C6DAEA314A4B
    Key-Arg   : None
    Start Time: 1146853049
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
drop connection and then reconnect
CONNECTED(00000003)
---
Reused, TLSv1/SSLv3, Cipher is ADH-AES256-SHA
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ADH-AES256-SHA
    Session-ID: 7EA1BD96E349CB6C0A9A289B4B5BE6BE0B2C66B02C1B769C3A2B75A8F7BAF90C
    Session-ID-ctx:
    Master-Key: 5D937FDECCFB1419333FF309753F4BB2F2AA016FAD1D2918DA50FEA24CE0EE9F939290A7942932F56054C6DAEA314A4B
    Key-Arg   : None
   Compression: 1 (zlib compression)
    Start Time: 1146853049
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
drop connection and then reconnect
CONNECTED(00000003)
---
Reused, TLSv1/SSLv3, Cipher is ADH-AES256-SHA
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ADH-AES256-SHA
    Session-ID: 7EA1BD96E349CB6C0A9A289B4B5BE6BE0B2C66B02C1B769C3A2B75A8F7BAF90C
    Session-ID-ctx:
    Master-Key: 5D937FDECCFB1419333FF309753F4BB2F2AA016FAD1D2918DA50FEA24CE0EE9F939290A7942932F56054C6DAEA314A4B
    Key-Arg   : None
   Compression: 1 (zlib compression)
    Start Time: 1146853049
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
drop connection and then reconnect
CONNECTED(00000003)
---
Reused, TLSv1/SSLv3, Cipher is ADH-AES256-SHA
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ADH-AES256-SHA
    Session-ID: 7EA1BD96E349CB6C0A9A289B4B5BE6BE0B2C66B02C1B769C3A2B75A8F7BAF90C
    Session-ID-ctx:
    Master-Key: 5D937FDECCFB1419333FF309753F4BB2F2AA016FAD1D2918DA50FEA24CE0EE9F939290A7942932F56054C6DAEA314A4B
    Key-Arg   : None
   Compression: 1 (zlib compression)
    Start Time: 1146853049
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
drop connection and then reconnect
CONNECTED(00000003)
---
Reused, TLSv1/SSLv3, Cipher is ADH-AES256-SHA
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ADH-AES256-SHA
    Session-ID: 7EA1BD96E349CB6C0A9A289B4B5BE6BE0B2C66B02C1B769C3A2B75A8F7BAF90C
    Session-ID-ctx:
    Master-Key: 5D937FDECCFB1419333FF309753F4BB2F2AA016FAD1D2918DA50FEA24CE0EE9F939290A7942932F56054C6DAEA314A4B
    Key-Arg   : None
   Compression: 1 (zlib compression)
    Start Time: 1146853049
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
drop connection and then reconnect
CONNECTED(00000003)
---
Reused, TLSv1/SSLv3, Cipher is ADH-AES256-SHA
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ADH-AES256-SHA
    Session-ID: 7EA1BD96E349CB6C0A9A289B4B5BE6BE0B2C66B02C1B769C3A2B75A8F7BAF90C
    Session-ID-ctx:
    Master-Key: 5D937FDECCFB1419333FF309753F4BB2F2AA016FAD1D2918DA50FEA24CE0EE9F939290A7942932F56054C6DAEA314A4B
    Key-Arg   : None
   Compression: 1 (zlib compression)
    Start Time: 1146853049
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
R
RENEGOTIATING
DONE

=============

============= s_server and s_client with "-bugs" ==============

Session resumption fails:

./apps/openssl s_client -bugs -cipher ADH -reconnect -connect localhost:12345
CONNECTED(00000003)
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 291 bytes and written 182 bytes
---
New, TLSv1/SSLv3, Cipher is ADH-AES256-SHA
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ADH-AES256-SHA
    Session-ID: 59F42BA09DB633A020F03C8F88C501FB593068D427D9FB2E5CA66E4B60D578E2
    Session-ID-ctx:
    Master-Key: 749FB45408C92BD0E53526472E5D7493C80099F59E93519B8EA16AEE6250759A59499255B4899F7DEE1F5CDBB601738C
    Key-Arg   : None
    Start Time: 1146853503
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
drop connection and then reconnect
CONNECTED(00000003)
15237:error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:s3_pkt.c:426:

Renegotiation fails:

$ ./apps/openssl s_client -bugs -cipher ADH -connect localhost:12345
CONNECTED(00000003)
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 291 bytes and written 182 bytes
---
New, TLSv1/SSLv3, Cipher is ADH-AES256-SHA
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ADH-AES256-SHA
    Session-ID: 4544EF7A0983EEED1B7CF2DE90279187B2B0DC5790D0988533E3F1CECD204F2D
    Session-ID-ctx:
    Master-Key: 86CD8B9FB5509A16DAC4899E722BB460542714739912915F1D6DA60C2D5BD2172F48B654B103365125D0253F0F593F59
    Key-Arg   : None
    Start Time: 1146853573
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
R
RENEGOTIATING
15266:error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:s3_pkt.c:426:

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 0.9.8b + zlib + "-bugs"?

Victor Duchovni
On Fri, May 05, 2006 at 02:43:20PM -0400, Victor Duchovni wrote:

>
> With 0.9.8a, and now also 0.9.8b, building with zlib and running with
> the usual bug workarounds ("-bugs" option) results in code that does
> not appear to handle session renegotiation correctly. Is compression
> incompatible with "-bugs", or is there an implementation issue?
>
> Some vendor distribution of OpenSSL enable all the bells and whistles
> (specifically at least zlib) and the resulting code may exhibit problems
> when connections are resumed and (SSL_OP_ALL) ("-bugs") is set.
>
> The documentation says:
>
>    It is usually safe to use SSL_OP_ALL to enable the bug workaround
>    options if compatibility with somewhat broken implementations is
>    desired.
>
> Is this still the case? Should applications (e.g. MTAs) that want
> maximum interoperability still set the SSL_OP_ALL options?
>
> ============= s_server and s_client without "-bugs" ==============
>
> [...]

The issue manifests directly at the initial connection if one disables
SSLv2 support (-no_ssl2), thereby allowing SSLv3/TLsv1 to negotiate
zlib compression right away. In this case the initial handshake fails
with "-bugs" enabled.

$ ./apps/openssl s_client -no_ssl2 -bugs -cipher ADH -connect localhost:12345
CONNECTED(00000003)
15938:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record mac:s3_pkt.c:1057:SSL alert number 20
15938:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:

Is *anyone* in a position to comment on this? I want to freeze the
TLS support in Postfix 2.3 rather soon, and if using SSL_OP_ALL is no
longer recommended (because OpenSSL 0.9.8[ab] installations that have
zlib enabled will be unable to establish or re-establish TLS sessions),
I need to know now... I asked essentially the same question when 0.9.8a
was new and got no response :-(

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 0.9.8b + zlib + "-bugs"?

Dr. Stephen Henson
On Sat, May 06, 2006, Victor Duchovni wrote:

> On Fri, May 05, 2006 at 02:43:20PM -0400, Victor Duchovni wrote:
>
> >
> > With 0.9.8a, and now also 0.9.8b, building with zlib and running with
> > the usual bug workarounds ("-bugs" option) results in code that does
> > not appear to handle session renegotiation correctly. Is compression
> > incompatible with "-bugs", or is there an implementation issue?
> >
> > Some vendor distribution of OpenSSL enable all the bells and whistles
> > (specifically at least zlib) and the resulting code may exhibit problems
> > when connections are resumed and (SSL_OP_ALL) ("-bugs") is set.
> >
> > The documentation says:
> >
> >    It is usually safe to use SSL_OP_ALL to enable the bug workaround
> >    options if compatibility with somewhat broken implementations is
> >    desired.
> >
> > Is this still the case? Should applications (e.g. MTAs) that want
> > maximum interoperability still set the SSL_OP_ALL options?
> >
> > ============= s_server and s_client without "-bugs" ==============
> >
> > [...]
>
> The issue manifests directly at the initial connection if one disables
> SSLv2 support (-no_ssl2), thereby allowing SSLv3/TLsv1 to negotiate
> zlib compression right away. In this case the initial handshake fails
> with "-bugs" enabled.
>
> $ ./apps/openssl s_client -no_ssl2 -bugs -cipher ADH -connect localhost:12345
> CONNECTED(00000003)
> 15938:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record mac:s3_pkt.c:1057:SSL alert number 20
> 15938:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
>
> Is *anyone* in a position to comment on this? I want to freeze the
> TLS support in Postfix 2.3 rather soon, and if using SSL_OP_ALL is no
> longer recommended (because OpenSSL 0.9.8[ab] installations that have
> zlib enabled will be unable to establish or re-establish TLS sessions),
> I need to know now... I asked essentially the same question when 0.9.8a
> was new and got no response :-(
>

This is ticket #1204 in RT.

A workaround for a bug in some implementations sometimes triggers a false
positive and can assume a bug is present in the peer when it is not. This
causes the problem you mention. This false positive will only normally occur
when compression is enabled.

If you don't set SSL_OP_TLS_BLOCK_PADDING_BUG then the code isn't used: that
should resolve your immediate problems.

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.

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                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 0.9.8b + zlib + "-bugs"?

Victor Duchovni
On Sat, May 06, 2006 at 10:58:57PM +0200, Dr. Stephen Henson wrote:

> > $ ./apps/openssl s_client -no_ssl2 -bugs -cipher ADH -connect localhost:12345
> > CONNECTED(00000003)
> > 15938:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record mac:s3_pkt.c:1057:SSL alert number 20
> > 15938:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
> >
> > Is *anyone* in a position to comment on this? I want to freeze the
> > TLS support in Postfix 2.3 rather soon, and if using SSL_OP_ALL is no
> > longer recommended (because OpenSSL 0.9.8[ab] installations that have
> > zlib enabled will be unable to establish or re-establish TLS sessions),
> > I need to know now... I asked essentially the same question when 0.9.8a
> > was new and got no response :-(
>
> This is ticket #1204 in RT.
>
> A workaround for a bug in some implementations sometimes triggers a false
> positive and can assume a bug is present in the peer when it is not. This
> causes the problem you mention. This false positive will only normally occur
> when compression is enabled.
>
> If you don't set SSL_OP_TLS_BLOCK_PADDING_BUG then the code isn't used: that
> should resolve your immediate problems.

So I take it that the recommendation is to use:

        (SSL_OP_ALL & ~SSL_OP_TLS_BLOCK_PADDING_BUG)

> 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?

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 0.9.8b + zlib + "-bugs"?

Dr. Stephen Henson
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                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 0.9.8b + zlib + "-bugs"?

Dr. Stephen Henson
On Sun, May 07, 2006, Dr. Stephen Henson wrote:

> On Sat, May 06, 2006, Victor Duchovni 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.

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.

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                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 0.9.8b + zlib + "-bugs"?

Kyle Hamilton
In reply to this post by Dr. Stephen Henson
On 5/6/06, Dr. Stephen Henson <[hidden email]> wrote:

> 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.

So.  How best to handle this?  Tell admins in the release notes that
you're going to keep an eye on the number of 'bad record mac' errors,
and if there's a much larger number than normal that you're going to
send a message to syslog saying they should report back to the OpenSSL
team?

I believe the TLS block padding bug was related to early
implementations of TLS in IE 4 or 5, but I cannot remember the history
reliably.  (This is, IIRC, why TLS 1.0 is disabled by default in most
everything pre-IE7.)

-Kyle H
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 0.9.8b + zlib + "-bugs"?

Victor Duchovni
In reply to this post by Dr. Stephen Henson
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                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 0.9.8b + zlib + "-bugs"?

Marek.Marcola
In reply to this post by Victor Duchovni
Hello,

> Interesting that the initial session is uncompressed, but the resumed
> session is...
With default configuration (enabled ssl2/3,tls1) OpenSSL client sends
SSL2 ClientHello packet (with TLS1 protocol version)
which has no support for compression information.

> I'll gladly test any snapshot that addresses this issue.
Simply way to disable TLS1_FLAGS_TLS_PADDING_BUG when compression
is compiled in AND when peer want to use compression is to change
line ssl/t1_enc.c:831 :
        if ((memcmp(s->s3->read_sequence,
                "\0\0\0\0\0\0\0\0",8) == 0) && !(ii & 1))
to someting like:
        if ((memcmp(s->s3->read_sequence,
                "\0\0\0\0\0\0\0\0",8) == 0) && !(ii & 1) && !s->expand)

> Is there any way to determine at run-time whether the
> OpenSSL library is a 0.9.8[ab] release with zlib enabled?
SSL_COMP_get_compression_methods() returns always NULL
when compression is not compiled in.

Best regards,
--
Marek Marcola <[hidden email]>

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 0.9.8b + zlib + "-bugs"?

Dr. Stephen Henson
In reply to this post by Victor Duchovni
On Sat, May 06, 2006, Victor Duchovni wrote:

>
> I'll gladly test any snapshot that addresses this issue.

OK, please try the next snapshot and/or this patch:

http://cvs.openssl.org/chngview?cn=15251

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                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 0.9.8b + zlib + "-bugs"?

Victor Duchovni
On Sun, May 07, 2006 at 02:36:10PM +0200, Dr. Stephen Henson wrote:

> On Sat, May 06, 2006, Victor Duchovni wrote:
>
> >
> > I'll gladly test any snapshot that addresses this issue.
>
> OK, please try the next snapshot and/or this patch:
>
> http://cvs.openssl.org/chngview?cn=15251
>

Preliminary testing with s_client and s_server looks good, initial
SSLv3/TLSv1 sessions, resumed sessions and renegotiation all work. I'll
build Postfix against the modified library and report the results here,
but that will likely take a few days. Thanks for looking into this,
I am looking forward to seeing this issue gone with 0.9.8c.

[ If it were up to me, I would push 0.9.8c out the door sooner rather
  than later. The more distributions ship 0.9.8[ab] with zlib support
  enabled, the more interoperability issues are likely to be encountered
  in the field with applications using SSL_OP_ALL. ]

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 0.9.8b + zlib + "-bugs"?

Victor Duchovni
In reply to this post by Victor Duchovni
On Sat, May 06, 2006 at 10:45:53PM -0400, Victor Duchovni wrote:

> 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?

It looks like I can call SSL_COMP_get_compression_methods(), and if I
get a non-null stack, check whether the stack depth is > 0.

    static void my_set_options(SSL_CTX *ctx)
    {
        long options = SSL_OP_ALL;

#if (OPENSSL_VERSION_NUMBER < 0x0090800fL) ||
        (OPENSSL_VERSION_NUMBER > 0x0090802fL)

    STACK_OF(SSL_COMP) *comp_methods;

        comp_methods = SSL_COMP_get_compression_methods();
        if (comp_methods != 0 && sk_SSL_COMP_num(comp_methods) > 0)
            options = SSL_OP_ALL & ~SSL_OP_TLS_BLOCK_PADDING_BUG;
#endif
        SSL_CTX_set_options(ctx, options);
    }

Does this seem sensible?

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 0.9.8b + zlib + "-bugs"?

Victor Duchovni
On Sun, May 07, 2006 at 04:28:22PM -0400, Victor Duchovni wrote:

> It looks like I can call SSL_COMP_get_compression_methods(), and if I
> get a non-null stack, check whether the stack depth is > 0.
>
>     static void my_set_options(SSL_CTX *ctx)
>     {
>         long options = SSL_OP_ALL;
>
> #if (OPENSSL_VERSION_NUMBER < 0x0090800fL) ||
> (OPENSSL_VERSION_NUMBER > 0x0090802fL)
>
>     STACK_OF(SSL_COMP) *comp_methods;
>
> comp_methods = SSL_COMP_get_compression_methods();
> if (comp_methods != 0 && sk_SSL_COMP_num(comp_methods) > 0)
>    options = SSL_OP_ALL & ~SSL_OP_TLS_BLOCK_PADDING_BUG;
> #endif
> SSL_CTX_set_options(ctx, options);
>     }
>
> Does this seem sensible?

The "#if ( < ) || ( > )" test is inverted, sorry too much on the fly
editing, but you get the idea... Is the general approach sensible?

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 0.9.8b + zlib + "-bugs"?

Dr. Stephen Henson
On Sun, May 07, 2006, Victor Duchovni wrote:

> On Sun, May 07, 2006 at 04:28:22PM -0400, Victor Duchovni wrote:
>
> > It looks like I can call SSL_COMP_get_compression_methods(), and if I
> > get a non-null stack, check whether the stack depth is > 0.
> >
> >     static void my_set_options(SSL_CTX *ctx)
> >     {
> >         long options = SSL_OP_ALL;
> >
> > #if (OPENSSL_VERSION_NUMBER < 0x0090800fL) ||
> > (OPENSSL_VERSION_NUMBER > 0x0090802fL)
> >
> >     STACK_OF(SSL_COMP) *comp_methods;
> >
> > comp_methods = SSL_COMP_get_compression_methods();
> > if (comp_methods != 0 && sk_SSL_COMP_num(comp_methods) > 0)
> >    options = SSL_OP_ALL & ~SSL_OP_TLS_BLOCK_PADDING_BUG;
> > #endif
> > SSL_CTX_set_options(ctx, options);
> >     }
> >
> > Does this seem sensible?
>
> The "#if ( < ) || ( > )" test is inverted, sorry too much on the fly
> editing, but you get the idea... Is the general approach sensible?
>

That will of course only perform the version comparison at compile time. If
OpenSSL shared libraries are updated without recomplining the source then
that might not do what you want. A runtime comparison would avoid that.

This looks like its one area which was overlooked since the SSLeay days.
Currently you have to use the function SSLeay() to get the version number at
runtime.

Some new functions with OPENSSL in them should be added.

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                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 0.9.8b + zlib + "-bugs"?

Victor Duchovni
On Mon, May 08, 2006 at 12:04:24AM +0200, Dr. Stephen Henson wrote:

> > > It looks like I can call SSL_COMP_get_compression_methods(), and if I
> > > get a non-null stack, check whether the stack depth is > 0.
> > >
> > >     static void my_set_options(SSL_CTX *ctx)
> > >     {
> > >         long options = SSL_OP_ALL;
> > >
> > > #if (OPENSSL_VERSION_NUMBER < 0x0090800fL) ||
> > > (OPENSSL_VERSION_NUMBER > 0x0090802fL)
> > >
> > >     STACK_OF(SSL_COMP) *comp_methods;
> > >
> > > comp_methods = SSL_COMP_get_compression_methods();
> > > if (comp_methods != 0 && sk_SSL_COMP_num(comp_methods) > 0)
> > >    options = SSL_OP_ALL & ~SSL_OP_TLS_BLOCK_PADDING_BUG;
> > > #endif
> > > SSL_CTX_set_options(ctx, options);
> > >     }
> > >
> > > Does this seem sensible?
> >
> > The "#if ( < ) || ( > )" test is inverted, sorry too much on the fly
> > editing, but you get the idea... Is the general approach sensible?
> >
>
> That will of course only perform the version comparison at compile time. If
> OpenSSL shared libraries are updated without recomplining the source then
> that might not do what you want. A runtime comparison would avoid that.

True, if I build with 0.9.8[ab], then the code will suppress the padding
bug work-around even with 0.9.8[c-z], or fail to suppress it on a regression
from 0.9.8[c-z] to 0.9.8[ab].

> This looks like its one area which was overlooked since the SSLeay days.
> Currently you have to use the function SSLeay() to get the version number at
> runtime.
>
> Some new functions with OPENSSL in them should be added.

Yes, indeed. Would it be appropriate for applications to check for the
same major/minor at runtime and compile time?

    if ((0xFFFFF000L & OPENSSL_VERSION_NUMBER) != (0xFFFFF000L & SSLeay())) {
    ... warning or perhaps even fatal error ...
    }

This would detect mismatches between headers and libraries. Usually the
library SONAME (on my system libssl.so.0.9.7) prevents run-time linking
of an incompatible library, but that too is not 100% foolproof. To date
there has been no expectation that different major.minor OpenSSL releases
will offer the same ABI.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]