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
(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´ve
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
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
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
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 have
committee.
Cheers,
Eric 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
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
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
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
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
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 PROTECTED]]On Behalf Of Le Saux, Eric
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
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
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
:[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]
Cc: [EMAIL PROTECTED]; [EMAIL
-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 maintains
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?
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+openssl-dev
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 several
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 connection is active
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
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, respectively,
when
-
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 wrote:
I believe Gregory Stark meant RFC2246
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 connection
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
27 matches
Mail list logo
