I don't think it does be default. The only what I know is to establish a compressed SSH tunnel to your server and then access the server over the tunnel. It will compress and give you an extra layer of encryption.

Umm, no. It will not compress. Think about it, encrypted data is fundamentally not compressible, that's the whole point.

johannes

...

...

I don't think it does be default. The only what I know is to establish a compressed SSH tunnel to your server and then access the server over the tunnel. It will compress and give you an extra layer of encryption.

Umm, no. It will not compress. Think about it, encrypted data is fundamentally not compressible, that's the whole point.

x = length(compress(encrypt(data))) y = length(encrypt(compress(data))) z = length(encrypt(data))

Then, usually, x > y and z > y, but x is approximately the same as z. (That's speaking very generally; there may be optimizations in some case or another given your data.)

That is: encrypted data is less compressible than the original data, but if you compress first, then encrypt, it should be a win.

If I recall correctly, a "compressed SSH tunnel" would do 'y' (compress then encrypt). i.e., dovecot would see a non-SSL connection which gets compressed-then-encrypted, or decrypted-then-uncompressed by the endpoints of the tunnel.

Well, as far as I understood Marc, since he was saying "an extra layer of encryption" I understood him to mean that he wanted to

encrypt(compress(encrypt(imap stream)))

by building an ssh-tunnelled imaps (or imap/tls) connection. IOW, dovecot would see an SSL connection too.

johannes

...

IOW, dovecot would see an SSL connection too.

Hmm, yes. I took it to mean that the 'encrypt' of

encrypt(compress(imap stream))

was the "extra layer". But, I think your interpretation is more easily arrived at, and if it's what Mark meant, you're absolutely right that the tunnel won't help.

A compressed SSH tunnel to regular, non-SSL IMAP should work to reduce traffic, though.

Absolutely. And it'll even be considered 'secure' since local connections are secure.

OTOH, if you're going to the trouble to use ssh anyway, can Thunderbird do something like a "connect command"? I use that in evolution, and mine looks like something like this: ssh -C mailserver '/usr/sbin/dovecot --exec-mail imap'

where 'mailserver' really is an alias in my .ssh/config

johannes

On Fri, 2008-06-20 at 23:04 +0100, Ed W wrote:

Johannes Berg wrote:

...

...

I don't think it does be default. The only what I know is to establish a compressed SSH tunnel to your server and then access the server over the tunnel. It will compress and give you an extra layer of encryption.

Umm, no. It will not compress. Think about it, encrypted data is fundamentally not compressible, that's the whole point.

We are way off topic...

:)

Back to the original question - discount SSH - how do we get compression + SSL out of openssl..

I don't think it's possible. OpenSSL says, in the NOTES section of SSL_COMP_add_compression_method(3):

    The TLS standard (or SSLv3) allows the integration of
    compression methods into the communication. The TLS RFC does
    however not specify compression methods or their corresponding
    identifiers, so there is currently no compatible way to
    integrate compression with unknown peers. It is therefore
    currently not recommended to integrate compression into
    applications. Applications for non-public use may agree on
    certain compression methods. Using different compression methods
    with the same identifier will lead to connection failure.

johannes

On Sat, 2008-06-21 at 00:13 +0200, Johannes Berg wrote:

...

...

Back to the original question - discount SSH - how do we get compression + SSL out of openssl..

I don't think it's possible. OpenSSL says, in the NOTES section of SSL_COMP_add_compression_method(3):

    The TLS standard (or SSLv3) allows the integration of
    compression methods into the communication. The TLS RFC does
    however not specify compression methods or their corresponding
    identifiers, so there is currently no compatible way to
    integrate compression with unknown peers. It is therefore
    currently not recommended to integrate compression into
    applications. Applications for non-public use may agree on
    certain compression methods. Using different compression methods
    with the same identifier will lead to connection failure.

However, there is http://tools.ietf.org/html/draft-ietf-tls-compression, but openssl doesn't support that (only zlib and rle)

I'm way behind the times. http://www.faqs.org/rfc/rfc3749.txt

johannes

On Sat, 2008-06-21 at 10:45 +0300, Timo Sirainen wrote:

...

However, digging deeper, it appears that COMP_zlib _is_ actually "deflate", so adding

SSL_COMP_add_compression_method(COMP_zlib());

should do the trick. Apparently it's compatible to gnutls too (see http://www.ietf.org/IESG/Implementations/rfc-3749-implementations.txt)

Oh, and the reason why I didn't even suggest the above was because the following code (0.9.8e):

int SSL_COMP_add_compression_method(int id, COMP_METHOD *cm) .. /* According to draft-ietf-tls-compression-04.txt, the compression number ranges should be the following:

   0 to 63:    methods defined by the IETF
   64 to 192:  external party methods assigned by IANA
   193 to 255: reserved for private use */
if (id < 193 || id > 255)
	{
	SSLerr(SSL_F_SSL_COMP_ADD_COMPRESSION_METHOD,SSL_R_COMPRESSION_ID_NOT_WITHIN_PRIVATE_RANGE);
	return 0;
	}

That makes it impossible to add standard compression methods..