From: "pobox" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: Re: OpenSSL and compression using ZLIB Date sent: Fri, 29 Nov 2002 15:22:18 -0600 Send reply to: [EMAIL PROTECTED]
I was not sure either, and perhaps I did not take the time to completely understand what Geoff was really saying. If so, I apologize. However I do agree with the statements below. The other thing that concerns me a little is the use of a zlib dll in the Microsoft Windows environment. OpenSSL 0.9.7 makes use a zlib dll, although it could be optional. The specs are not really clear in this area, and I have always had to mess around with the final makefile to get compression and the Kerberos option to even work. I have been burned several times with the use of zlib dll's, since quite a few Windows based programs distribute zlib dll's and not all are compatible, but all appear to have the same exports. However, this is not an issue if in there is an option to use static zlib functions linkage. Getting the OpenSSL zlib support to operate like the statements below, with the ability the specify a compression level would allow us, and other Windows based developers of SSH clients, get rid of some redundent logic. Most developers of these clients already use the OpenSSL EVP cipher support. I suspect most UNIX SSH developers do also. We also use zlib compression within our SSL/TLS based telnet client which communicates mainly with the SRP project telnet server. Ken > 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] ___ Support InterSoft International, Inc. Voice: 888-823-1541, International 281-398-7060 Fax: 888-823-1542, International 281-398-0221 [EMAIL PROTECTED] http://www.securenetterm.com ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
