Date sent: Wed, 27 Nov 2002 14:58:24 -0500
From: Geoff Thorpe <[EMAIL PROTECTED]>
Subject: Re: OpenSSL and compression using ZLIB
To: [EMAIL PROTECTED]
Copies to: "Le Saux, Eric" <[EMAIL PROTECTED]>, royop@tb-
solutions.com
Send reply to: [EMAIL PROTECTED]
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.
Ken
On November 27, 2002 12:33 pm, Le Saux, Eric wrote:
> Yes, very interesting.
>
> This is another way of adding compression to the data pipe.
> I have not looked at the code, but I assume that the compression state
> is maintained for the whole life of the communication channel, which is
> what gives the best results.
Um, out of curiosity ... wouldn't this be the easiest way to implement a
custom compression method anyhow? Ie. define the compression method so
that the SSL/TLS handshake can take care of agreeing (or not) about
compression at each end, but do not implement the method inside SSL/TLS
processing - ie. if that compression method is agreed, cause a zlib BIO
to be inserted (or removed, in the case of a renegotiation perhaps) onto
the application side of the SSL object's BIO chain (um, actually
"chains", one each for read and write I suppose) ... this essentially
does what Pablo was referring to but lets the SSL/TLS handshake take care
of negotiating compression with the peer. The latter is the problem with
just putting the compression layer inside the SSL/TLS layer, you need an
out-of-band (read: application) mechanism to decide when to use it or
not.
It sounds a bit magic(k) though ... hmm ... perhaps buffering/flushes
would be the problem when applications use non-blocking sockets? If not,
this sounds easier than putting the zlib manipulation inside the SSL/TLS
layer and would probably give faster and better compression too.
oh yes: Pablo J Royo wrote;
> I think the BIO would mantain the context (as z_stream struct of ZLIB
> do) among several calls to BIO_write/read, so if you want to compress
> communication data you have to chain this "zBIO" with a socket BIO.
almost - presumably the socket BIO you refer to is on the SSL/TLS data
side rather than the application data side, in which case your
compression won't do much. Compression is only useful on the assumption
that the application data itself is compressible, and by the time you get
SSL/TLS data - it's (hopefully) too well encrypted for compression to
have much effect. :-) I assume you ment to chain it with a memory/buffer
BIO? Ie. going from;
--> write_BIO --> >-- \
[app] [SSL] socket_BIO
<-- read_BIO <-- <-- /
to;
--> write_BIO --> zlib_BIO --> >--\
[app] [SSL] socket_BIO
<-- read_BIO <-- zlib_BIO <-- <--/
?
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
___________________________________________________________________
___
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]
