Hi there, On November 29, 2002 04:22 pm, pobox wrote: > 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:
[snip] I think my point ended up running orthogonally to the discussion taking place :-) I was speaking from an implementation perspective and suggesting that the compression and decompression *defined* and in the custom SSL/TLS compression methods could have its *implementation* completely decoupled from the SSL/TLS record layer code. It seems SSL/TLS compression is supposed to compress the data prior to encrypting/MACing, so there seems little point implementing those compression details inside that SSL/TLS record layer code. With OpenSSL's SSL/TLS implementation relying heavily on BIOs already (be that for better or worse), it seems that a very simple and possibly optimal way of implementing compression would be simply to plonk two compression BIOs in the appropriate chains whenever our "custom" SSL/TLS compression method is negotiated at the SSL/TLS level. The alternative is to have various bits and pieces of zlib logic splattered throughout the SSL/TLS code despite the fact that it seems to do little more than just filter the application data through zlib. With respect to your 3 forms - they sort of collapse into one under this scheme though could be kept separated via BIO_ctrl()s if desired. Eg. if you define more than one compression method to handle different flushing and/or dictionary semantics, you could make the corresponding "BIO hooks" in the SSL/TLS handshake code just prep the (de)compression BIOs with an appropriate BIO_ctrl(). Ideally, "regular" compression should work OK and the flushing should mirror how applications see "regular" SSL/TLS already. Ie. if [BIO|SSL]_write(10 bytes of data) normally goes straight out and generates a new SSL record, then the compression case should compress the 10 bytes before doing the same. If applications and/or the SSL/TLS implementation uses buffering under certain circumstances, that should take effect at the compression layer too (ie. trying to reduce fragmentation and SSL/TLS bandwidth overhead should likewise improve compression quality by compressing larger blocks). There should be no reason to reset the compressor state in *any* way, as SSL/TLS already stipulates the requirement for an ordered and reliable data stream. However forcing such behaviour should be easy enough for compatibility purposes if required. (Note this approach keeps compression code in BIOs without duplicating it in ssl/, so applications can use the BIOs independantly too. Also, new compression methods are easier to add - eg. define a libbzip2-based BIO and add a new compression id+hook in the SSL/TLS code). Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ Strange yet thought-provoking time of year; Muslims spend a month of Rammadan, fasting and reflecting. Americans celebrate liberty with a day full of eating. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
