Re: OpenSSL and compression using ZLIB

[pobox]

 On November 27, 2002 03:24 pm, Kenneth R. Robinette wrote:
  Um, well that's one approach.  But its a little like saying Lets let
  SSL/TLS take care of agreeing on a cipher type, and then leave it up to
  the user application to take care of the actual encryption/decrytion.
  I would rather see the most commonly used methods inplemented within
  SSL/TLS itself.

 If the SSL/TLS implementation is doing the (de)compression I don't see
 what your point is. Ie. with this compression method negotiated by the
 client and server, the SSL/TLS would still be responsible for handling
 compression - it would just handle it on the application data before
 applying the SSL/TLS framing rather than compressing data inside it. From
 the application point of view, there's no need to implement anything. Did
 you misunderstand me or vice versa?


Geoff,

I can't speak for Kenneth, but I'm not sure I get what you're saying
here. The data is first compressed and then encrypted according to
RFC2246. In my mind, once the application hands the data to OpenSSL
via SSL_write() or BIO_write() or _puts() or whatever it is no longer
application data, even if compression has been negotiated.

I think it is best to firstly get the decompressor correct. My belief
is that a single decompressor can transparently handle the following
three possible compression scenarios:

1) Each record is compressed independently. The dictionary is reset
before each record. This appears to be the way OpenSSL currently works
(flush is Z_FULL_FLUSH). Compression ratio is worst of the three.

2) The dictionary is not reset between records.  However, the current
compression buffer can be flushed (Z_SYNC_FLUSH), so that uncompressed
data does not span an SSL record boundary. Compression ratio is better
than #1.

3) The compression buffer is not flushed between records. Uncompressed
data may span SSL record boundaries. Best compression ratio.

#1 is the 'safest' in that it seems to make compression as
transparently to client applications as is possible. #2 is almost as
safe. For the most part, #2 will be just as safe as #1. In fact, I
can't really think of any reasonable scenarios in which this is not
true, but strange things are possible with acceleraters, proxies,
shims and whatnot. At least #2 is absolutely necessary, e.g. for
client protocols like EAP-TLS.

A decompressor that has this functionality would be backward
compatible with the current OpenSSL scheme and forward compatible with
almost any reasonable implementation of ZLIB over TLS.




__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #361] OpenSSL and compression using ZLIB

[pobox via RT]

- Original Message -
From: Jeffrey Altman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, November 24, 2002 8:26 AM
Subject: Re: OpenSSL and compression using ZLIB


 http://www.ietf.org/internet-drafts/draft-ietf-tls-compression-03.txt

 defines the compression numbers to be:

enum { null(0), ZLIB(1), LZS(2), (255) } CompressionMethod;

 Therefore proposed numbers have been issued.  I suggest that OpenSSL
 define the CompressionMethod numbers to be:

enum { null(0), ZLIB(1), LZS(2), eayZLIB(224), eayRLE(225), (255) }
 CompresssionMethod

 as values in the range 193 to 255 are reserved for private use.

 Where does the above draft state that the dictionary must be reset?
 It states that the engine must be flushed but does not indicate that
 the dictionary is to be reset.  Resetting the dictionary would turn
 ZLIB into a stateless compression algorithm and according to the draft
 ZLIB is most certainly a stateful algorithm:

  the compressor maintains it's state through all compressed records

 I do not believe that compatibility will be an issue.  It will simply
 result in the possibility that the compressed data is distributed
 differently among the TLS frames that make up the stream.


The draft clearly implies that the dictionary need not be reset and probably
should not be reset, but it is not clear to me that it prohibits this.
However, the draft talks about ...
If TLS is not being used with a protocol that provides reliable, sequenced
packet delivery, the sender MUST flush the compressor completely ...
I find this confusing because I've always understood that TLS assumes it is
running over just such a protocol. If I read it correctly, even EAP-TLS (RFC
2716) will handle sequencing, duped, and dropped packets before TLS
processing is invoked. So what's this clause alluding to?

In any event, I think I agree that the compressor can compatibly behave in
different ways as long as the decompressor doesn't care. I'm just not sure I
understand RFC1950 and 1951 well enough to know what is possible. Is flush
the compressor completely (as in the TLS compression draft language)
equivalent to compressing all the current data and emitting an end-of-block
code (value=256 in the language of RFC1951)? I'm guessing it is. Is
resetting the dictionary equivalent to compressing all the current data
and sending the block with the BFINAL bit set? If so, then it seems like the
decompressor can always react correctly and therefore compatibly in any of
the three cases. If the dictionary is reset for every record (current
OpenSSL behavior), then the decompressor knows this because the BFINAL bit
is set for every record. If the dictionary is not reset but is flushed for
every record, then the decompressor knows this because every record ends
with and end-of-block code. If the most optimal case is in play, which
implies a single uncompressed plaintext byte might be split across multiple
records, the decompressor can recognize and react properly to this case. If
all this is correct, then the next question is ...
What will the current implementation of thedecompressor in OpenSSL do in
each of these cases?


--greg
[EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]