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?
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
