0.9.8c and zlib, to enable or not to enable?

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

0.9.8c and zlib, to enable or not to enable?

Victor Duchovni

I see that the padding bug work-around incompatibility issue with zlib
is slated to be fixed in 0.9.8c. At that point I see no critical reason
to not enable "zlib" support in our internal 0.9.8c build.

RFC 3749 says:

   However, combining compression with encryption can sometimes reveal
   information that would not have been revealed without compression:
   data that is the same length before compression might be a different
   length after compression, so adversaries that observe the length
   of the compressed data might be able to derive information about
   the corresponding uncompressed data.  Some symmetric encryption
   ciphersuites do not hide the length of symmetrically encrypted data
   at all.  Others hide it to some extent, but still do not hide it
   fully.  For example, ciphersuites that use stream cipher encryption
   without padding do not hide length at all; ciphersuites that use
   Cipher Block Chaining (CBC) encryption with padding provide some
   length hiding, depending on how the amount of padding is chosen.
   Use of TLS compression SHOULD take into account that the length of
   compressed data may leak more information than the length of the
   original uncompressed data.

So, will compression be on by default in all applications when "zlib"
support is enabled in 0.9.8c, or will applications be expected to
specifically turn compression on? If compression is on by default,
will applications be able choose to disable it?

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