I’m using openSUSE 12.2 with apache 2.2.22 (all patches installed). There has been no back-port to use
SSL_COMPRESSION=off
in /etc/apache2/httpd.conf. I’ve tried adding
export OPENSSL_NO_DEFAULT_ZLIB=1
to /etc/sysconfig/apache2, but that too does not disable compression when using the TLS protocol. Thus the webserver is still vulnerable to the CRIME attack.
Is there any way to disable compression for TLS when using apache 2.2.22 and openSUSE 12.2?
On 2013-03-27 00:06, paul pech wrote:
> Thus the webserver is still vulnerable to
> the CRIME attack.
I know nothing about that, but if you think that openSUSE’s apache is
vulnerable to some attack, there are two places to report: one is the
security mail list, and another is bugzilla.
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
which is not surprising because I haven’t bothered to enable ssl
> I’m wondering why the proposed workaround (adding “export
> OPENSSL_NO_DEFAULT_ZLIB=1” to /etc/sysconfig/apache2) does not work with
> openSUSE.
I don’t know, but my initial recommendation still holds, because that
way you reach the people in charge of security issues and can tell you
an authoritative answer.
paul pech wrote:
> I’m wondering why the proposed workaround (adding “export
> OPENSSL_NO_DEFAULT_ZLIB=1” to /etc/sysconfig/apache2) does not work with
> openSUSE.
As Carlos said, you’re better off asking questions like this on the
security list and in bugzilla
On 2013-03-27 13:56, paul pech wrote:
>
> Thanks Carlos for pointing me in the right direction;
>
> https://bugzilla.novell.com/show_bug.cgi?id=779952
>
> As it seems, a patch is available today for SLE and they’re considering
> it for openSUSE, too. I hope it makes its way there.
Yes.
But I wonder why if the vulnerability has been known for a year why it
took so long to create a patch…
> I’ll ask questions like this on the security mailing list from now on.
> Anyways, thanks for the replies.
Welcome
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
According to the article, although you can do due diligence patching server-side, the most practical immediate solution is to just ensure the client web browsers are patched to latest, apparently all have been patched (see list in isecpartners link). If you want to enforce client browser versions, only requires a little javascript in the page’s head.
It also looks like you an also upgrade to Apache 2.4 which does allow SSL compression configuration, but for 2.2 there is no User accessible config unless you’re willin to tear into the C code.
the hack doesn’t work because there is no software hook, doesn’t exist in the module for Apache 2.2. So, it appears someone noticed and implemented a hook in 2.4 which has became immediately useful.
That’s the problem with hacks… You can’t just send commands willy nilly, something somewhere has to accept and understand the command.
The article I referenced also describes the near non-existent support for SSL/TLS compression anyway (at least for everyone who updates their software) so the actual numbers of people who might be compromised is fairly small. So, bottom line is that like everything else when a problem is no longer rated “critical” it’s anyone’s guess when and if the problem is addressed.