LibreSSL has removed compression support. Tor should check for the OPENSSL_NO_COMP define before trying to disable compression at runtime.
diff --git a/src/common/tortls.c b/src/common/tortls.c index e06a2ae..0f98968 100644 --- a/src/common/tortls.c +++ b/src/common/tortls.c @@ -1314,10 +1314,12 @@ tor_tls_context_new(crypto_pk_t *identity, unsigned int key_lifetime, SSL_CTX_set_options(result->ctx, SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION); } +#ifndef OPENSSL_NO_COMP /* Don't actually allow compression; it uses ram and time, but the data * we transmit is all encrypted anyway. */ if (result->ctx->comp_methods) result->ctx->comp_methods = NULL; +#endif #ifdef SSL_MODE_RELEASE_BUFFERS SSL_CTX_set_mode(result->ctx, SSL_MODE_RELEASE_BUFFERS); #endif
/* Don't actually allow compression; it uses ram and time, but the data * we transmit is all encrypted anyway. */ result->ctx->comp_methods = NULL;
This comment is confusing. Why are you asserting/mixing the two with the ', but' that 'encryption anyway' is excuse to not compress due to 'ram/time'? They are two separate things. Either you are encrypting compressed data, or encrypting uncompressed data.
On Sun, Jul 13, 2014 at 07:20:29PM -0400, grarpamp wrote:
/* Don't actually allow compression; it uses ram and time, but the data * we transmit is all encrypted anyway. */ result->ctx->comp_methods = NULL;
This comment is confusing. Why are you asserting/mixing the two with the ', but' that 'encryption anyway' is excuse to not compress due to 'ram/time'? They are two separate things. Either you are encrypting compressed data, or encrypting uncompressed data.
It seems to me the intent of the comment is that the *plaintext* data being transmitted is already encrypted (at another layer), and so is not going to be compressible, so don't waste ram/time trying to do so.
- Ian
On Sun, Jul 13, 2014 at 7:23 PM, Ian Goldberg iang@cs.uwaterloo.ca wrote:
On Sun, Jul 13, 2014 at 07:20:29PM -0400, grarpamp wrote:
/* Don't actually allow compression; it uses ram and time, but the data * we transmit is all encrypted anyway. */ result->ctx->comp_methods = NULL;
This comment is confusing. Why are you asserting/mixing the two with the ', but' that 'encryption anyway' is excuse to not compress due to 'ram/time'? They are two separate things. Either you are encrypting compressed data, or encrypting uncompressed data.
It seems to me the intent of the comment is that the *plaintext* data being transmitted is already encrypted (at another layer), and so is not going to be compressible, so don't waste ram/time trying to do so.
I though this portion referred to compress then encrypt, not encrypt then compress (which would of course be pointless). ie: I thought the openssl zlib routines were to compressed then encrypted.
On Sun, Jul 13, 2014 at 11:01:23PM -0400, grarpamp wrote:
On Sun, Jul 13, 2014 at 7:23 PM, Ian Goldberg iang@cs.uwaterloo.ca wrote:
On Sun, Jul 13, 2014 at 07:20:29PM -0400, grarpamp wrote:
/* Don't actually allow compression; it uses ram and time, but the data * we transmit is all encrypted anyway. */ result->ctx->comp_methods = NULL;
This comment is confusing. Why are you asserting/mixing the two with the ', but' that 'encryption anyway' is excuse to not compress due to 'ram/time'? They are two separate things. Either you are encrypting compressed data, or encrypting uncompressed data.
It seems to me the intent of the comment is that the *plaintext* data being transmitted is already encrypted (at another layer), and so is not going to be compressible, so don't waste ram/time trying to do so.
I though this portion referred to compress then encrypt, not encrypt then compress (which would of course be pointless). ie: I thought the openssl zlib routines were to compressed then encrypted.
Yes, that's right. But the data to be (optionally compressed then) encrypted is, in Tor, typically *already* encrypted by the application layer, so compressing then encrypting that is not better than just re-encrypting it.
- Ian
-
grarpamp -
Ian Goldberg -
Pascal Stumpf