I made the necessary changes in c_zlib.c a few days ago. Please test it and if there
are errors, report that as a new ticket. This one is now resolve.
[[EMAIL PROTECTED] - Mon Nov 25 09:50:34 2002]:
> http://www.ietf.org/internet-drafts/draft-ietf-tls-compression-03.txt
>
> defines the compr
>(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).
I agree with this.
I
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 BI
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 eit
> 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 r
>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.
I must admit I didn´t think in this problem when I posted my message (I´m not an
expert :-( ), because I hav
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
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 PR
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 give
SSL_COMP_add_compression_method() also?
Cheers,
Eric Le Saux
Electronic Arts
-Original Message-
From: Pablo J Royo [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 27, 2002 12:27 AM
To: [EMAIL PROTECTED]
Subject: Re: OpenSSL and compression using ZLIB
I have used ZLIB in several projects, but my
f the dictionary that you use. Future
> compression methods supported by SSL will probably have their own
different
> set of options.
>
> All this will be an excellent subject of discussion in some SSL standard
> committee.
>
> Cheers,
>
> Eric Le Saux
> Electronic Arts
>
On Tue, Nov 26, 2002 at 02:00:43PM -0500, Geoff Thorpe wrote:
>
> Thanks for describing what you're up to and thanks (in advance) for
> contributing your implementation(s). OpenSSL is used for a lot more
> than building free webservers, despite misconceptions to the contrary,
> and having an reaso
Salut Eric,
Thanks for describing what you're up to and thanks (in advance) for
contributing your implementation(s). OpenSSL is used for a lot more than
building free webservers, despite misconceptions to the contrary, and
having an reasonably-optimal zlib compression layer right there in the
c Le Saux
Electronic Arts
-Original Message-
From: Howard Chu [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 25, 2002 9:01 PM
To: [EMAIL PROTECTED]
Subject: RE: OpenSSL and compression using ZLIB
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTE
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Le Saux, Eric
> In the current implementation of OpenSSL,
> compression/decompression state is
> initialized and destroyed per record. It cannot possibly
> interoperate with
> a compressor that maintai
ECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: OpenSSL and compression using ZLIB
>
> - Original Message -
> From: "Jeffrey Altman" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>; <[EMAIL PRO
:[EMAIL PROTECTED]]
Sent: Sunday, November 24, 2002 2:43 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: OpenSSL and compression using ZLIB
- Original Message -
From: "Jeffrey Altman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
On Mon, Nov 25, 2002 at 09:54:13AM +0100, Richard Levitte - VMS Whacker via RT wrote:
>
> In message <001601c2940a$deed1b60$06a8a8c0@dell8200> on Sun, 24 Nov 2002 16:43:12
>-0600, "pobox" <[EMAIL PROTECTED]> said:
>
> ghstark> What will the current implementation of thedecompressor in
> ghstark>
In message <001601c2940a$deed1b60$06a8a8c0@dell8200> on Sun, 24 Nov 2002 16:43:12
-0600, "pobox" <[EMAIL PROTECTED]> said:
ghstark> What will the current implementation of thedecompressor in
ghstark> OpenSSL do in each of these cases?
Unless this can be determined, it can be tested by having se
- 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/inter
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 {
In message <001601c2940a$deed1b60$06a8a8c0@dell8200> on Sun, 24 Nov 2002 16:43:12
-0600, "pobox" <[EMAIL PROTECTED]> said:
ghstark> What will the current implementation of thedecompressor in
ghstark> OpenSSL do in each of these cases?
Unless this can be determined, it can be tested by having sev
- 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
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 {
In message <[EMAIL PROTECTED]> on Sun, 24 Nov 2002 10:10:26 +0100, "Peter
'Luna' Runestig" <[EMAIL PROTECTED]> said:
peter+openssl-dev> Gregory Stark wrote:
peter+openssl-dev> > Oops, I meant 2246. And reading it more
peter+openssl-dev> > carefully, I agree with your interpretation. The
peter+op
Gregory Stark wrote:
Oops, I meant 2246. And reading it more carefully, I agree with your
interpretation. The dictionary need not be reset. Compression state can and
should be maintained across records.
So, is anyone working on improving the zlib code according to these new
guidelines?
Cheers
>
> >6.2.2. Record compression and decompression
> >
> >[snip snip] The compression algorithm translates a
> >TLSPlaintext structure into a TLSCompressed structure. Compression
> >functions are initialized with default state information whenever a
> >connection state is made active.
>
> The connect
>6.2.2. Record compression and decompression
>
>[snip snip] The compression algorithm translates a
>TLSPlaintext structure into a TLSCompressed structure. Compression
>functions are initialized with default state information whenever a
>connection state is made active.
The conne
ove
SSL.
-
Eric
-Original Message-
From: David Schwartz [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November
12, 2002 4:24 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Le Saux, Eric
Subject: RE: OpenSSL and compression using ZLIB
On Tue, 12 Nov
2002 18:09:13 -0600, Le
Saux, Eric w
>>I am trying to understand why ZLIB is being used that way. Here is what
>>gives better results on a continuous reliable stream of data:
>>
>>1) You create a z_stream for sending, and another z_stream for
>>receiving.
>>
>>2) You call deflateInit() and inflateInit() on them, respecti
ious one in the OpenSSL use of
compression. Is it an architectural constraint?
Eric Le Saux
Electronic Arts
-Original Message-
From: Bear Giles [mailto:bgiles@;coyotesong.com]
Sent: Monday, November 11, 2002 8:14 PM
To: [EMAIL PROTECTED]
Subject: Re: OpenSSL and compression using ZLIB
Le Saux, Eric wrote:
I am trying to understand why ZLIB is being used that way. Here is what
gives better results on a continuous reliable stream of data:
1) You create a z_stream for sending, and another z_stream for
receiving.
2) You call deflateInit() and inflateInit() on the
OpenSSL (0.9.6g) has
support for compression, both using RLE and ZLIB.
The way ZLIB is used, calls to the compress()
function are made on each block of data transmitted.
Compress() is a
higher-level function that calls deflateInit(),
deflate() and deflateEnd().
I am trying to understa
33 matches
Mail list logo